Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Ubuntu Kernel Team (http://www.linux-archive.org/ubuntu-kernel-team/)
-   -   UBUNTU: SAUCE: AppArmor: allow newer tools to loadpolicyon older kernels (http://www.linux-archive.org/ubuntu-kernel-team/427812-ubuntu-sauce-apparmor-allow-newer-tools-loadpolicyon-older-kernels.html)

Tetsuo Handa 09-16-2010 12:37 PM

UBUNTU: SAUCE: AppArmor: allow newer tools to loadpolicyon older kernels
 
John Johansen wrote:

> On 09/15/2010 02:41 PM, Tetsuo Handa wrote:
> > John Johansen wrote:
> >> security/apparmor/policy_unpack.c | 3 ---
> >> 1 files changed, 0 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/security/apparmor/policy_unpack.c b/security/apparmor/policy_unpack.c
> >> index 6b0637b..ef11ba9 100644
> >> --- a/security/apparmor/policy_unpack.c
> >> +++ b/security/apparmor/policy_unpack.c
> >> @@ -575,9 +575,6 @@ static struct aa_profile *unpack_profile(struct aa_ext *e)
> >>
> >> size = unpack_array(e, "net_allowed_af");
> >> if (size) {
> >> - if (size > AF_MAX)
> >> - goto fail;
> >> -
> >> for (i = 0; i < size; i++) {
> >> if (!unpack_u16(e, &profile->net.allow[i], NULL))
> >
> > If this patch changes to accept size > AF_MAX , this patch should change
> > to allocate net.allow[size] rather than net.allow[AF_MAX] .
> >
> >> goto fail;
>
> yes it should, I did make that change but it looks like I didn't push it
> to the remote repo from which I pulled :(

But allocating net.allow[size] is useless because kernel would reject before
calling LSM hooks if size > AF_MAX . Then, read and discard is sufficient?

--- a/security/apparmor/policy_unpack.c
+++ b/security/apparmor/policy_unpack.c
@@ -575,7 +575,7 @@

size = unpack_array(e, "net_allowed_af");
if (size) {
- for (i = 0; i < size; i++) {
+ for (i = 0; i < size && i < AF_MAX; i++) {
if (!unpack_u16(e, &profile->net.allow[i], NULL))
goto fail;
if (!unpack_u16(e, &profile->net.audit[i], NULL))
@@ -583,6 +583,20 @@
if (!unpack_u16(e, &profile->net.quiet[i], NULL))
goto fail;
}
+ /*
+ * A newer version of userspace tools might support more
+ * address families than this kernel supports. Read and discard
+ * address families which are not supported by this kernel.
+ */
+ for (; i < size; i++) {
+ u16 dummy;
+ if (!unpack_u16(e, &dummy, NULL))
+ goto fail;
+ if (!unpack_u16(e, &dummy, NULL))
+ goto fail;
+ if (!unpack_u16(e, &dummy, NULL))
+ goto fail;
+ }
if (!unpack_nameX(e, AA_ARRAYEND, NULL))
goto fail;
/*

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

Tetsuo Handa 09-21-2010 02:13 PM

UBUNTU: SAUCE: AppArmor: allow newer tools to loadpolicyon older kernels
 
Tim Gardner wrote:
> So, whats the impact? Does this mean that we're dropping all AA rules?

At first, I thought the impact of this error is

When a profile with address family which currently running kernel does not
know is loaded, loading the profile will succeed but all networking
permissions are discarded. Therefore, currently running kernel will reject
all socket operations (e.g. socket(), bind(), sendmsg()) for all families
(except AF_UNIX and AF_NETLINK) with -EACCES unless the process is
unconfined. This means that networking applications (e.g. firefox, cupsd,
dhclient) which will be confined by profiles won't work properly.

But after reading security/apparmor/net.c , it changed to:

No impact at all because Maverick kernel does not provide networking
mediation functionality.

What? Excuse me, John. I assumed that networking mediation functionality is
included into Maverick kernel. But according to
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=blob;f=security/apparmor/net.c;hb=HEAD
(as of "ALSA: seq/oss - Fix double-free at error path of snd_seq_oss_open()"),
I can't find a line that stores error code to sa.aad.error within audit_net().
This means that sa.aad.error is always 0 and therefore aa_net_perm() will
always return 0 (rather than -EACCESS) no matter how "net_allowed_af" is
specified.

I hope I'm missing something...

--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team

John Johansen 09-21-2010 04:29 PM

UBUNTU: SAUCE: AppArmor: allow newer tools to loadpolicyon older kernels
 
On 09/21/2010 07:13 AM, Tetsuo Handa wrote:
> Tim Gardner wrote:
>> So, whats the impact? Does this mean that we're dropping all AA rules?
>
> At first, I thought the impact of this error is
>
> When a profile with address family which currently running kernel does not
> know is loaded, loading the profile will succeed but all networking
> permissions are discarded. Therefore, currently running kernel will reject
> all socket operations (e.g. socket(), bind(), sendmsg()) for all families
> (except AF_UNIX and AF_NETLINK) with -EACCES unless the process is
> unconfined. This means that networking applications (e.g. firefox, cupsd,
> dhclient) which will be confined by profiles won't work properly.
>
> But after reading security/apparmor/net.c , it changed to:
>
> No impact at all because Maverick kernel does not provide networking
> mediation functionality.
>
> What? Excuse me, John. I assumed that networking mediation functionality is
> included into Maverick kernel. But according to
> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=blob;f=security/apparmor/net.c;hb=HEAD
> (as of "ALSA: seq/oss - Fix double-free at error path of snd_seq_oss_open()"),
> I can't find a line that stores error code to sa.aad.error within audit_net().
> This means that sa.aad.error is always 0 and therefore aa_net_perm() will
> always return 0 (rather than -EACCESS) no matter how "net_allowed_af" is
> specified.
>
> I hope I'm missing something...

Unfortunately, no. The error is being set but dropped in the audit fn, it
seems I broke it during the auditing update, and that the regression test
suite for networking is broken. I'll get the SRU patch out immediately.


--
kernel-team mailing list
kernel-team@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/kernel-team


All times are GMT. The time now is 02:53 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.