[apparmor] AppArmor 2.8 beta2

[John Johansen]

On 03/13/2012 01:39 PM, Christian Boltz wrote:
> Hello,
> 
> Am Montag, 12. März 2012 schrieb John Johansen:
>> On 03/12/2012 03:42 PM, Christian Boltz wrote:
>>> 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.
> 
> My usual viewpoint is the filesystem POV. Hey, it's just a program or 
> FTP user that is chrooted, not me ;-)
> 
Well yes, I can understand to pov.  I don't want to take away the ability
to express profiles in the form.  Just mark them up in such a way that
the tools can correctly interpret what needs to be done, and can continue
to be done with changes in the underlying implementation.

There is a mess of confusion around file system namespace, chroots and
profiles that needs to be made consistent.

> Additionally, there might be overlaps inside and outside the chroot - 
> and I'd like to avoid that a program gets too much permissions in the 
> "real" filesystem. Just think of
>     /** rw,
> which is quite common for a chrooted FTP user in chroot_relative 
> notation. You don't want to (accidently) apply this rule for the real 
> filesystem ;-)
> 
I would NEVER propose overlaping pre and post chroot paths, that is just
broken. And indeed its one of the failure points that is encountered
with fs namespaces atm, and will be until full implicit labeling comes on
line.

Because fs namespaces don't have root requirements that are the same
as chroots, there is no way to get back to the pre namespace change
path, and the attach_disconnected flag must be used, which effectively
causes the overlap you just pointed out above.


>> 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.
> 
> Most probably yes if we are talking about a sub OS (because that makes 
> it easier to use abstractions etc.), but for just chrooting FTP users I 
> prefer using the full path.
> 
> Anyway, we seem to agree that the main profile should always use the 
> full path.
> 
It would be easier, but there is going to need to be some magic, especially
around fs namespaces, which are being used interchangeably in some places.

>> I think the other thing you are missing is chroot rules, which where
>> supposed to land in 2.8 but didn't.  
> 
> Yes, I've seen the discussion, but somehow failed to ask earlier ;-) 
> ENOTIME, ETOOMUCHONTODOLIST or something alike. 
> Sorry for asking that late.
> 
>> 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.
> 
> OK, if we have something like
> 
>     chroot /home/www/*/ -> ^subprofile
> 
> then it can make sense to make this subprofile chroot_relative. 
> However I don't see why we can't just explicitely specify the 
> chroot_relative flag on the ^subprofile to make it clear. The parser 
> could even warn if a chroot target profile is not flagged as 
> chroot_relative or namespace_relative.
> 
Hehe but you be able to.

> Another idea would be (to enable using existing profiles or subprofiles 
> without the need to add a chroot_relative flag on them):
> 
>     chroot /home/www/*/ -> ^subprofile (chroot_relative)
> 
I am open to ideas, since we are reverting all of it from 2.8 there is
more time to kick around the design and requirements
> 
> Everything else should stay namespace_relative because of
> - backward compability (never change the meaning of a profile!)

I understand this pov, but this may not even be possible in the future or
at least not in the current form.  This is one of the reasons to begin
pushing for the change.  The other being consistency between chroot and
fs namespaces.

If we break things I promise it will be a fail closed situation.

We need to mark up one or the other case, and the chroot case for profiles
is much less common, so its the one we should be targeting.

There are things we can do to auto detect, like chroot rules with no
transition means the profile is being mixed and should be using namespace
relative.

Even in namespace relative profiles I would like to see moving to a
variable root, for chroot paths

Eg.

  chroot /home/www/*,

  @{root}/foo rw,

its not required but it would aid in analysis and make it easier to get
a tighter dynamic profile.

> - principle of least surprise (just think you know nothing about 
>   AppArmor and your first contact is by reading a profile) - which 
>   behaviour would you expect in the main profile?
> 
well again define main profile?

> If we really want to do such a change, we should finally implement 
> versioning in the profiles - there were lots of discussions about this, 
> but until now nobody implemented it ;-)
> 
Well, we can always bring that discussion up again
> 
> BTW: I remember that a very old version of AppArmor (2.3?) was indeed 
> chroot_relative. I always thought of that as a bug (which might even 
> introduce security issues if chroot and the real filesystem overlap) and 
> was very happy when it was fixed^Wchanged.
> 
2.0 I think, maybe 2.1 but I doubt it

> Needless to say that I like your proposal to revert to 
> namespace_relative by default ;-)
> 
well you get your wish :)