Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing ListRe: [PATCH 08/28] SECURITY: Allow kernel services to override LSM settings for task actions [try #2]
From: Stephen Smalley <sds_at_tycho.nsa.gov>
Date: Tue, 11 Dec 2007 16:34:07 -0500
I didn't say that. I said that LSM provides no standard way for userspace to access the security infrastructure, at least beyond the raw /proc/self/attr and xattr APIs, and I view that as a defect in LSM. SELinux does have a userspace API, because we think there should be a way for userspace to do that, and it is being used by userspace programs outside of security tools.
> > > Is linking against libselinux is a viable option if it's not available under All your code has to do is invoke a function provided by libselinux. If at some later time a liblsm is introduced that provides a common front-end to a libselinux, libsmack, ..., then you can use that. But it doesn't exist today. But it all just becomes a simple function call regardless.
> > - your kernel interface should be generic, and your LSM hooks should be The point being that userspace is already using the SELinux API directly - cachefilesd certainly won't be the first or most crucial application to do so.
> > > > > I use to do that, but someone objected... Possibly Karl MacMillan. Well, he can speak to that. But regardless, he isn't the maintainer.
> > > > It doesn't fit with how other users of security_kernel_act_as() will You can certainly make the linking conditional at compile time based on a build flag, and/or you can dlopen it at runtime and fall back gracefully if not present. It isn't tying your program to libselinux, just using it if present, in this case to obtain an input to supply to your kernel module so that the "policy" of deciding what context to use is completely determined in userspace and not hardcoded at all into the kernel. If init and ls and ps can do it, cachefilesd can too.
> Furthermore, I worked out "the right way to do this" with some apparent I did express reservations about it, and I really don't think that this is the main obstacle - the determination of the acting task security label and how to set it is really only a small part of your patch set, and considerably less disruptive than the rest of it.
> How about I just stick the context in /etc/cachefilesd.conf as a textual That mostly works, but it means that an update to policy may require an update to /etc/cachefilesd.conf, or that switching from one policy to another might likewise require changing that file. Versus using a separate policy-provided config file for the label. BTW, as should be obvious, some LSMs aren't label-based at all, so it would need to be optional. -- Stephen Smalley National Security Agency -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.Received on Tue 11 Dec 2007 - 16:34:11 EST |
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |