linux-kernel - Re: Btrfs v0.14 Released

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <c24352ca0805020715y46741317ve9897afd689d058f@mail.gmail.com>
Date:	Fri, 2 May 2008 07:15:32 -0700
From:	"Jeff Schroeder" <jeffschroed@...il.com>
To:	"Chris Mason" <chris.mason@...cle.com>
Cc:	"Jan Engelhardt" <jengelh@...ozas.de>,
	"Jeff Mahoney" <jeffm@...e.com>,
	"Tim Gardner" <tim.gardner@...onical.com>,
	linux-fsdevel@...r.kernel.org, kernel-team@...ts.ubuntu.com,
	linux-kernel@...r.kernel.org, linux-btrfs@...r.kernel.org,
	"John Johansen" <jjohansen@...e.de>
Subject: Re: Btrfs v0.14 Released

On Fri, May 2, 2008 at 5:52 AM, Chris Mason <chris.mason@...cle.com> wrote:
> On Friday 02 May 2008, Jan Engelhardt wrote:
>  > On Thursday 2008-05-01 22:10, Jeff Mahoney wrote:
>  > >>>> Couldn't you #ifdef based on CONFIG_SECURITY_APPARMOR ? This ought to
>  > >>>> work for Hardy. However the next development kernel (Intrepid) does
>  > >>>> not have the APPARMOR patches, so just knowing that its an UBUNTU
>  > >>>> kernel is not specific enough.
>  > >>>
>  > >>> I've been assuming the apparmor patches change remove_suid even when
>  > >>> they are not enabled in the config.
>  > >>
>  > >> Lets get Kees involved. He developed the patch set for Hardy. I would
>  > >> hope that if CONFIG_SECURITY_APPARMOR=n then the source would default to
>  > >> its normal state.
>  > >
>  > >remove_suid() isn't the only change AppArmor makes to the VFS interface.
>  > >It's pretty invasive and requires that dentries are passed with a
>  > >companion vfsmount in most cases. Putting #ifdefs around all that code
>  > >would make the problem worse, not better.
>  >
>  > An alternative approach, and IMHO better suited, is to:
>  >
>  >       make -C ${kdir} all I_HAZ_AN_APPARMOR=1
>
>  This is better than the current situation (oops without any clues), but I'd
>  prefer that people not have to know what apparmor is or if they have it.
>  (This isn't a knock on apparmor, I'd just rather take care of it
>  automagically).

Chris,

Make is not my forte, but here is a working test to see if apparmor
exists in Ubuntu 8.04.
Maybe have make apply a patch to the btrfs source if this test
succeeds? Does this work in SUSE?

http://www.digitalprognosis.com/opensource/patches/btrfs/lame_apparmor_test_for_btrfs.patch

The symlink from /lib/modules/`uname -r`/build ->
/path/to/kernel/headers/ doesn't exist on CentOS 5.
Even though it is a hack, is this or something like it usable? Or is
this the completely wrong direction?

-- 
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/