Messages in this thread | | | Date | Thu, 27 Apr 2006 03:17:34 -0700 | From | Chris Wright <> | Subject | Re: Some Concrete AppArmor Questions - was Re: [RFC][PATCH 0/11] security: AppArmor - Overview |
| |
* 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.
thanks, -chris - 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/
| |