[apparmor] AppArmor 2.8 beta2
John Johansen
john.johansen at canonical.com
Mon Mar 12 23:19:26 UTC 2012
On 03/12/2012 03:42 PM, Christian Boltz wrote:
> Hello,
>
> Am Samstag, 10. März 2012 schrieb John Johansen:
>> * profiles have been defaulted to chroot relative instead of namespace
>> relative
>
> What does that mean in practise?
>
> To give a real-world example: I have a profile for vsftpd [1] that
> allows
> /home/www/*/httpdocs/** rw,
>
> Users are chrooted to their home directory (/home/www/*/) when they
> login with FTP.
>
> Do I have to change my profile to
> /httpdocs/** rw,
> (which would be bad IMHO)?
yes. As to bad yes and no it depends on how you are developing your
policy. From a visibility view point it makes a lot of sense, from
a I want to think about this from a system filesystem pov not so
much.
Think of it like this, You are virtualizing a sub OS in a chroot
what should its profiles look like?
Well host system profiles would want to see the full path (namespace_relative)
and profiles loaded inside the chroot would want to be chroot_relative.
I think the other thing you are missing is chroot rules, which where
supposed to land in 2.8 but didn't. This would mean instead of staying
in the say profile at chroot point, you could transition into another
say a child profile, which would only list what was available from within
the chroot.
> If yes, which keyword/flag do I have to add to avoid this?
>
namespace_relative, its been supported for a while
eg. /bin/foo (namespace_relative) { }
> (That said: does this introduce a syntax change/addition that is not
> listed in your "2.8 syntax changes" mail?)
>
No syntax changes, just which flag value namespace_relative or chroot_relative
was defaulted.
The end game is to change how we are doing path lookups in the kernel
and be consistent between chroots and filesystem namespaces.
However it is looking more and more like we are not ready for this transition
and I may revert some or all of the patches until the 3.0 release. That would
mean the behavior was consistent through the 2.x series and give us a little
more time to prepare.
More information about the AppArmor
mailing list