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: David Howells <dhowells_at_redhat.com>
Date: Tue, 11 Dec 2007 20:42:05 +0000
> > That sounds too SELinux specific. How do I do it so that it works for any So, basically, userspace programs (outside of security tools) aren't supposed to need access to the security infrastructure?
> > Is linking against libselinux is a viable option if it's not available under It is if I have to maintain a special pieces of code for each possible LSM. One piece for SELinux, one piece for AppArmour, one piece for Smack, one piece for Casey's security system. That sounds like a pain.
> - your kernel interface should be generic, and your LSM hooks should be In /usr/bin ldd reports approximately 297 binaries link to libselinux, though I can't say how many of those linked against it directly rather than picking it up by contamination through a shared library. Furthermore, I've no idea how many more find it by dlopen.
> > > > I use to do that, but someone objected... Possibly Karl MacMillan. Not that I know of.
> > > It doesn't fit with how other users of security_kernel_act_as() will True. I'd rather have separate security for each.
> Why are you opposed to having userspace determine the context and write it Because, from what I gather, that means my userspace program needs to do something different, depending on the security model that's currently in force on a system. Furthermore, I would have to have separate code, as far as I know, for each security model as there's no commonality in userspace. I can't just link against libselinux. It might not be there. I'm not going to tie my program to SELinux either. Furthermore, I worked out "the right way to do this" with some apparent SELinux person, and you seemed reasonably accepting of it. Now I have to go and redo all the work, having had to redo the security stuff a couple of times already because someone objected. *That* is the main obstacle to getting my code accepted at the moment, I think. How about I just stick the context in /etc/cachefilesd.conf as a textual configuration item and have the daemon pass that as a string to the cachefiles kernel module, which can then ask LSM if it's valid to set this context as an override, given the daemon's own security context? That seems entirely reasonable to me. David -- 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 - 15:43:32 EST |
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |