Matthew Wilcox wrote:
On Sun, Apr 13, 2008 at 06:41:19PM -0700, Crispin Cowan wrote:
Rather, it is "can write to /tmp/ntpd/*". You *grant* permissions. You
do *not* throw deny rules.
So primarily we're concerned here with things that are running as root,
daemons and the like. Normal unix file permissions (or ACLs, if you
must) are adequate to handle anything not running as uid 0.
That's not true. Both AppArmor and SELinux Targeted Policy address
confinement of both root and non-root applications. Examples:
* Confining even non-root applications keeps them from accessing
world and group accessible files.
* Many services run as nobody instead of root, and smarter ones
create themselves a new UID to run as. Even so, confining them is
useful because the least-privilege posture is much easier to
specify and verify in a capability model (as SELinux and AppArmor
are) than an ACL model (as permission bits on files are).
* You may want to confine a desktop application. E.g. Pidgin is a
great IM tool because it speaks so many protocols, but with that
large functionality comes a large attack surface, and it has had
vulnerabilities from time to time. A confined IM client can be
configured to only have access to your IM files, and not e.g. your
SSH private keys.
I don't see what apparmour and tomoya buy us that namespaces can't.
Controlled overlap. You can use AppArmor to confine every *individual*
piece of a web site shopping cart, and yet they still can interact with
each other by sharing files. You cannot do that with namespaces.
Conversely, it is very convenient to use namespaces to set up private
virtual domains, and that is not at all convenient to do with AppArmor,
TOMOYO, or SELinux.
The correct answer is to use namespaces for total isolation (virtual
domain hosting) and LSM confinement tools for security within a virtual
domain.
Maybe a nicer interface, but that's something that a nice userspace
management interface can handle.
Not true. Ease of management of access control is about the security
model. Cute GUIs help, but not much.
Create an empty namespace. Create /tmp/ntpd in it. Bind the outside
/tmp/ntpd onto that directory. Presto, the equivalent to an allow-rule
of 'can write to /tmp/ntpd/*'.
Now get ntpd to show you that you need to do this, in one pass. If you
already know all of the files to be accessed, and you are going to write
the security policy by hand, then the two approaches might be kind of
comparable. But that's not how AppArmor policies are created. This is
not a minor distinction.
The equivalent of 'can read, but not write /home/crispin/.ssh/id_rsa.pub'
will need r-o bind mounts, which Miklos seems to have become distracted
from by working on the hooks for TOMOYA.
Do you have a good example of something that apparmour can protect against
that namespaces can't?
See above. The major classes of things that namespaces can't do are:
* deliberate overlap
* learning mode
* wild cards, e.g. 'can read /var/www/**.html' to grant access to
all of the HTML files in the tree, but not the .pl source code files
Crispin
--
Crispin Cowan, Ph.D. http://crispincowan.com/~crispin
The Olympic Games: Symbolizing oppressiiion and corruption for over a
hundred years
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
