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 List
subject: about the safety problem in SELinux Date: Wed, 14 May 2003 19:13:17 +0200
What about SELinux?
I know some of the people who subscribed this mail list are not sure
SELinux is safe. But in the Flask doc it's written the control over
right propagation is provided by ensuring that the security policy is
consulted every time an object has to be accessed (e.g. for every
security decision). Another thing that let me guess SELinux should be
safe is that almost everything is configured by TE (RBAC support is very
poor) and, above all, it is statically configured.
How could a subject acquire a right which is not granted by the security
policy?
Is it right what I am thinking about or I am on the wrong way? (I am developing a small tool for policy analisis purpose, for my Graduate School Thesis, and if SELinux is safe it would be of more value...) Thank you and sorry if what I wrote is silly ;) Giorgio Il servizio Postemail sottopone tutti i documenti a una scansione automatica antivirus con i programmi TREND MICRO. -- 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: about the safety problem in SELinux Date: 15 May 2003 08:50:33 -0400
SELinux implements MAC, so a process cannot transfer rights (descriptors) to another process unless the recipient process is also authorized to access the object in the same manner by the MAC policy (which can only be changed administratively). SELinux controls descriptor inheritance across execve (when security context transitions occur for a process) and descriptor transfer via Unix domain socket IPC. It also typically revalidates permission on access to deal with revocation due to a file relabel or policy change; however, this is not yet complete - we do not presently provide revocation for memory-mapped files. Security context transitions are controlled by the policy, as are file relabels. Of course, proving specific security properties requires an analysis of the particular policy configuration. SELinux just provides the mechanism for enforcing the policy.
> I completely agree, but SELinux seems safe to me not becouse of RBAC Correct. However, some people like to use the RBAC component as a further boundary on domain transitions, e.g. you could potentially allow domain D1 to transition to domain D2 but only permit role R1 to enter domain D1 and role R2 to enter domain D1 and domain D2. Using the RBAC component in that manner is a bit dangerous, as you have to make sure that there aren't any other permissions granted from D1 to D2 that could allow R1:D1 to interfere with R2:D2, e.g. signal permissions. -- Stephen Smalley <sds@epoch.ncsc.mil> 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.From: Christopher J. PeBenito <pebenito_at_ieee.org> subject: slow application of contexts in devfs? Date: 15 May 2003 11:31:51 -0500
SELinux: Completing initialization.
SELinux: initialized (dev 03:03, type ext3), uses PSIDs SELinux: initialized (dev 00:08, type devpts), uses transition SIDs SELinux: initialized (dev 00:07, type devfs), uses genfs_contexts SELinux: initialized (dev 00:06, type binfmt_misc), not configured forlabeling SELinux: initialized (dev 00:05, type pipefs), uses task SIDs SELinux: initialized (dev 00:04, type tmpfs), uses transition SIDs SELinux: initialized (dev 00:03, type sockfs), uses task SIDs SELinux: initialized (dev 00:02, type proc), uses genfs_contexts SELinux: initialized (dev 00:01, type bdev), not configured for labeling SELinux: initialized (dev 00:00, type rootfs), not configured forlabeling Mounted devfs on /dev Freeing unused kernel memory: 280k freed avc: denied { write } for pid=148 exe=/sbin/devfsd path=/log dev=00:07 ino=421 scontext=system_u:system_r:devfsd_t tcontext=system_u:object_r:device_t tclass=sock_file Now, I've verified that the genfscon does exist, grepped out of policy.conf: genfscon devfs /log system_u:object_r:devlog_t Its also not just devfsd getting denials, there is a denial on syslog later on in the boot process. By the time the machine is done starting up, /dev/log does have the right context: srw-rw-rw- root root system_u:object_r:devlog_t /dev/log -- Chris PeBenito <pebenito@ieee.org> AIM: PeBenito78 ICQ#: 10434387 "Engineering does not require science. Science helps a lot, but people built perfectly good brick walls long before they knew why cement works."-Alan Cox -- 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: slow application of contexts in devfs? Date: 15 May 2003 15:02:58 -0400
/dev/log is a name for a Unix domain socket created by syslogd. Until syslogd is running and has bound a socket to /dev/log, writing to /dev/log isn't going to work regardless of your policy. When syslogd binds its socket to /dev/log, then it will pick up the correct type based on the file type transition rule, as with other file creations. Why does /dev/log even exist in devfs before syslogd has bound to it? -- Stephen Smalley <sds@epoch.ncsc.mil> 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.From: Russell Coker <russell_at_coker.com.au> subject: Re: slow application of contexts in devfs? Date: Fri, 16 May 2003 09:45:45 +1000
/dev/log doesn't exist in devfs before syslogd has run. My guess is that syslogd is running in the wrong domain and therefore the type transition does not apply. "ps ax --context | grep syslogd" should give a good clue. Of course for this to happen the machine must have booted in permissive mode. Christopher, would you happen to be running something other than the regular syslogd? Maybe a different syslogd with a file name that doesn't match the pattern? -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- 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.From: Christopher J. PeBenito <pebenito_at_ieee.org> subject: Re: slow application of contexts in devfs? Date: 15 May 2003 22:12:01 -0500
Chris
On Thu, 2003-05-15 at 18:45, Russell Coker wrote:
-- Chris PeBenito <pebenito@ieee.org> AIM: PeBenito78 ICQ#: 10434387 "Engineering does not require science. Science helps a lot, but people built perfectly good brick walls long before they knew why cement works."-Alan Cox -- 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.From: Russell Coker <russell_at_coker.com.au> subject: Re: slow application of contexts in devfs? Date: Fri, 16 May 2003 15:13:26 +1000
Please tell us the file name so it can be included into the standard policy to avoid other people having the same problem.
> its running in the correct domain. The fact (which didnt occur to me This is the way it should be. devfsd starts before sysklogd in Debian too and everything works fine. Are you running that cut-down syslogd that Red Hat uses for the early stages of their boot process (the one that causes all the problems)? If so make sure that it is also labelled with the correct context, and also please tell us the file name. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: slow application of contexts in devfs? Date: 16 May 2003 07:40:44 -0400
/dev/log shouldn't exist in devfs prior to syslogd (or metalog) starting. But perhaps your devfsd is automatically restoring /dev entries from a backup when it initializes, thereby creating an orphaned /dev/log that is subsequently removed and re-created by syslogd. You may need to grant syslogd permission to unlink device_t:sock_file so that it can remove the orphaned /dev/log left by devfsd. -- Stephen Smalley <sds@epoch.ncsc.mil> 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.From: Christopher J. PeBenito <pebenito_at_ieee.org> subject: Re: slow application of contexts in devfs? Date: 17 May 2003 12:05:38 -0500
I agree with your assessment, Stephen. There is an entry for /dev/log in devfsd's "dev-state" directory. Devfsd is restoring this on its startup. So, I added: REGISTER ^log CFUNCTION devfsd-se.so set_sid $devname system_u:object_r:devlog_t to my devfsd conflet. That took care of metalog's unlink denial for /dev/log. However, devfsd still gets the denial writing to to /dev/log because its still system_u:object_r:device_t. Its somewhat confusing; I would have thought that the write to /dev/log would be after devfsd's initialization, so /dev/log would have the correct context. Another option would be to try to stop devfsd from saving /dev/log into dev-state in the first place. Then /dev/log shouldn't be restored at all. This is seeming like the cleaner/saner option. The binary for metalog is metalog. If you'd like to look at it: http://metalog.sourceforge.net/. I like it because of it's built-in rotation of logs based on age or size, and simple configuration. The problem is that metalog is klogd+syslogd, so it doesnt fit in syslogd_t nicely (I didn't try running it in klogd_t, that might work better). I just added policy to syslogd.te. -- Chris PeBenito <pebenito@ieee.org> AIM: PeBenito78 ICQ#: 10434387 "Engineering does not require science. Science helps a lot, but people built perfectly good brick walls long before they knew why cement works."-Alan Cox -- 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.From: Russell Coker <russell_at_coker.com.au> subject: Re: slow application of contexts in devfs? Date: Sun, 18 May 2003 05:11:19 +1000
It will log the fact that it is changing the SID of /dev/log...
> Another option would be to try to stop devfsd from saving /dev/log into That is the correct option.
> The binary for metalog is metalog. If you'd like to look at it: I have been considering merging the two domains for smaller systems. Maybe it would be worth doing for the general case? The difference between them is that klogd can read system_map_t (*), and the kernel message log, while syslogd is permitted network access, can write files to disk under /var/log, and can create /dev/log. By merging the two we allow syslogd to read system map files under /boot which isn't that important and we allow syslogd to read the kernel message log directly (as it gets all the same data indirectly anyway that does not seem a problem). klogd gets to write files under /var/log and to create a socket under /dev. Is this enough of a problem to need a separate domain? (*) The current policy allows reading file and lnk_file objects of boot_t as well. A quick test suggests that klogd does not need such boot_t file access and I have changed my policy accordingly. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- 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.From: Christopher J. PeBenito <pebenito_at_ieee.org> subject: Re: slow application of contexts in devfs? Date: 18 May 2003 00:01:37 -0500
Most Gentoo users tend to use syslogs that don't have a separate klogd (syslog-ng, metalog, msyslog), so I've been merging klogd and syslogd. In the case of sysklogd, we felt that it was reasonable to run klogd and syslogd in the same domain. Of course theres nothing stopping the users from getting the separate syslogd and klogd policies if they really want it.
On Sat, 2003-05-17 at 14:11, Russell Coker wrote:
-- Chris PeBenito <pebenito@ieee.org> AIM: PeBenito78 ICQ#: 10434387 "Engineering does not require science. Science helps a lot, but people built perfectly good brick walls long before they knew why cement works."-Alan Cox -- 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: slow application of contexts in devfs? Date: 19 May 2003 08:37:16 -0400
klogd can be redirected to a particular file rather than going through syslogd, and syslogd may be set up to accept remote logging requests as well as local ones. Hence, it may be worthwhile to keep them as separate domains in the example policy, even if people choose to fold them in certain environments. -- Stephen Smalley <sds@epoch.ncsc.mil> 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.From: Stephen Smalley <sds_at_epoch.ncsc.mil> subject: Re: slow application of contexts in devfs? Date: 19 May 2003 07:39:18 -0400
Given that it performs rotation of the logs, you may want to also look into integrating the logrotate.te policy and the logrotate patch into metalog. The logrotate patch is necessary to ensure that the log security contexts are preserved when they are rotated. -- Stephen Smalley <sds@epoch.ncsc.mil> 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.From: Russell Coker <russell_at_coker.com.au> subject: Re: slow application of contexts in devfs? Date: Mon, 19 May 2003 23:10:59 +1000
logrotate runs scripts related to log file rotation on behalf of daemons (generally scripts to do whatever is necessary to cause the daemon to use the new files). Having all this done in the main syslogd_t domain is probably not desirable. But then having all the things in logrotate_t that are currently in it probably isn't a good idea either. Maybe if we change logrotate to use a different domain for those scripts then we could have it run in syslogd_t. Another issue is that it would be nice to have syslogd only be able to create and append to log files, not delete or modify. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page -- 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.From: Christopher J. PeBenito <pebenito_at_ieee.org> subject: Re: slow application of contexts in devfs? Date: 19 May 2003 09:35:44 -0500
On Mon, 2003-05-19 at 06:39, Stephen Smalley wrote:
-- Chris PeBenito <pebenito@ieee.org> AIM: PeBenito78 ICQ#: 10434387 "Engineering does not require science. Science helps a lot, but people built perfectly good brick walls long before they knew why cement works."-Alan Cox -- 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.From: Faye <faye_at_lurking-grue.org> subject: SE Linux mentioned in large Australian newspaper website Date: Thu, 3 Jul 2003 09:18:30 +1000
http://www.theage.com.au/articles/2003/07/02/1056825450368.html faye -- Message from Our Sponsor on ttytv at 00:01 ... Faye Coker faye@lurking-grue.org Current stomping ground: Melbourne, Australia -- 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.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |