Messages in this thread | | | Subject | Re: Some Concrete AppArmor Questions - was Re: [RFC][PATCH 0/11] security: AppArmor - Overview | From | Stephen Smalley <> | Date | Fri, 28 Apr 2006 09:00:06 -0400 |
| |
On Thu, 2006-04-27 at 15:38 -0700, Chris Wright wrote: > * Stephen Smalley (sds@tycho.nsa.gov) wrote: > > Not sure about the example here, as the type in that case would actually > > be lost upon the cp by the unconfined process to the /tmp location, in > > which case you have an issue for both AA and SELinux - the data has > > become accessible under a different name and label which may now be > > accessible beyond the original intent. > > Point is, names matter as much as inodes do. And it's possible to > get improperly labelled data in canonical location for object (i.e. > /etc/shadow). Certainly requires unconfined help, but real people do > things like that w/out fully understanding the impact. You can fix the > normal tools, but not all one-off admin tools.
The names don't matter as much as the real security properties of the data, but I do agree that mislabeling of data is an issue, particularly for a gradual rollout of MAC where we have to deal with the fact that not everything will be confined and not all of userspace will be properly instrumented. However, I'd argue that this can be addressed, in the short term through userspace tools like restorecond that leverage inotify and in the long term through ever expanding application of MAC to the system (as that becomes more feasible via the introduction of appropriate tools and infrastructure to make management feasible, which is already in progress). Addressing it by introducing a flawed mechanism into the kernel seems like a bad idea to me.
> > Of course, the real problem here > > is that you have an unconfined process copying the data at all, at which > > point you have no real guarantees about it, and the loss in label is the > > least of your worries. > > That's my point. You can't meaningfully reason about the security of > the system with unconfined processes.
Precisely. And this is something that we recognize and are working toward eliminating - the targeted policy is just a way of transitioning MAC into Linux gradually until we have the necessary infrastructure and tools to make it truly manageable. Whereas other approaches seem to presume that unconfined processes will always be present, and in fact, will be the majority of the system.
-- Stephen Smalley National Security Agency
- 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/
| |