Re: Some Concrete AppArmor Questions - was Re: [RFC][PATCH 0/11] security: AppArmor - Overview

[Karl MacMillan <kmacmillan@tresys.com>]

On Thu, 2006-04-27 at 03:17 -0700, Chris Wright wrote:
> * Andi Kleen (ak@suse.de) wrote:
> > > > 3/ Is AppArmour's approach of using d_path to get a filename from a
> > > >    dentry valid and acceptable? 
> > 
> > I suppose it needs at least to use the proper vfsmounts instead of
> > walking the global list. That would need better hooks. And probably 
> > some caching (trying to match dentries directly?) to get better performance.
> 
> Yes, walking the list is ugly.  I think you'd wind up having to pin
> those dentries in memory (or do what DTE tried with a shadow tree).
> 
> > Regarding the basic use of pathnames I don't see a big problem. After
> > all the kernel uses dentries for everything too and dentries are
> > just a special form of path name too.
> 
> The biggest issue with pathnames is they are non-determinstic,
> esp. when recreated after the fact using d_path.  So the pathname as
> object argument makes sense when talking about objects (vfsmont/dentry),
> not strings (d_path).  Also, when mediating solely on pathname it's very
> difficult to reason about the contents of the inode that's pointed to by
> the pathname.  This means that policy which allows a subject the ability
> to write to the object whose handle is /tmp/my_unimportant_tmpfile may be
> a security problem if somebody in the system was tricked into a simple 'ln
> /etc/shadow /tmp/my_unimportant_tmpfile.'  In this case it's surprising
> that the same inode can have different permissions (esp. given traditional
> DAC uid/gid and mode bits are kept in inode) depending upon path taken.
> 
> The AA stance is that the policy will protect the confined process from
> doing such namespace manipulations eliminating the possibiilty of the
> confined process and giving itself a mechanism to privilege escalation.
> This is reasonable with the caveat that the channels available to the
> confined process to collude with (or coerce) an unconfined process are
> still pretty high-bandwidth.  One could argue that having unconfined
> processes is ill-advised.  SELinux targeted policy has the same basic
> issue (channel richness notwithstanding), which is why I'd expect truely
> security sensitive environments would use a strict policy.
> 
> I guess it's worth noting the AA atack is stopped by SELinux, while the
> opposite is also true.  A 'cp /etc/shadow /tmp; mv /tmp/shadow /etc' done
> by an unconfined process doesn't effect AA, while it kills the type
> label on /etc/shadow and could be an effective policy breach.  In each
> case somewhat subtle (i.e. not explicit relabel or policy change) can
> have holes.
> 

While this is example of labeling issues with SELinux is correct for a
standard targeted policy, it does not represent an intrinsic problem
with the SELinux mechanism. A policy that has the appropriate
specialized domains for reading /etc/shadow and corresponding
type_transition rules can prevent this mislabeling. The solution may not
be very satisfying because of the changes it makes to how systems are
typically administered, but at least it does exist within the SELinux
model. The same cannot be said of the problems introduced by path-based
mechanisms.

Thanks,

Karl

> thanks,
> -chris
> -
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/