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: matchfilecon (the program) vs matchfilecon (the libselinux1 fn) Date: Sun, 1 Aug 2004 18:27:51 +0100
does anyone know: the matchfilecon program reads
does the matchfilecon libselinux1 api does the same? or does it read a binary policy from somewhere?
the reason i ask is because if i were to code up stuff into
udev, it might solve the problem of having to move
l. -- 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: matchfilecon (the program) vs matchfilecon (the libselinux1 fn) Date: Mon, 02 Aug 2004 10:00:23 -0400
Do you mean matchpathcon? No matchfilecon here. matchpathcon(1) is just a trivial test program that invokes the matchpathcon(3) library function on its arguments and reports the result. matchpathcon(3) reads the installed file_contexts configuration (/etc/selinux/$SELINUXTYPE/contexts/files/file_contexts), not the one from the policy source tree, as policy sources are optional. Binary policy isn't relevant here, as it doesn't contain file contexts. BTW, policy does live in /etc/selinux in Fedora Core 3 (or /etc/security/selinux in Fedora Core 2), and sounds like Russell has likewise moved it there in Debian. -- 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: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn) Date: Mon, 2 Aug 2004 15:57:24 +0100
yes.
> No matchfilecon here. matchpathcon(1) is ack, ta.
> Binary yes, i believe so - this is 1.14. so, conclusion, it's almost irrelevant as to whether matchpathcon(1) or matchpathcon(3) are used. therefore, i might as well leave udev's code alone. ... one thing though: running udev, it can only generate about 4 device inodes per second when having to do /etc/dev.d/defaults/selinux.dev (which calls restorecon $DEVICENAME). that's _awfully_ slow. especially when creating 64 /dev/ttyxx nodes, 64 /dev/ttySxx nodes, and then a few /dev/ramX nodes too. it delays boot-time by over 30 seconds, basically. what, if anything, could be done about this? run a restorecon asynchronous service? yes, i realise that sounds a bit mad, but if people are going to throw 150 device inodes up at boot-time, it's got to be quick. l. -- 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: matchfilecon (the program) vs matchfilecon (the libselinux1 fn) Date: Mon, 02 Aug 2004 10:52:05 -0400
What's the objection to patching udev to directly invoke matchpathcon(3) and setfscreatecon(3) prior to creating each device node? -- 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: matchfilecon (the program) vs matchfilecon (the libselinux1 fn) Date: Mon, 02 Aug 2004 11:00:02 -0400
BTW, if anyone does so, please pass the actual file mode to matchpathcon(3), so that proper file type matching can be done against the file_contexts configuration. -- 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: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn) Date: Mon, 2 Aug 2004 20:12:43 +0100
time! how long do those function calls take? using /sbin/restorecon, which is the present hack, each device node creation takes around a quarter of a second (!!) l. -- 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: matchfilecon (the program) vs matchfilecon (the libselinux1 fn) Date: Mon, 02 Aug 2004 15:19:16 -0400
Directly invoking the library functions has to be faster than exec'ing a separate helper program (restorecon) that then invokes the library functions. Further, restorecon has to re-lookup the device node in the filesystem, whereas udev can set up its context upon initial creation. Further, matchpathcon() caches the file context specification upon the first call, so if the udev process stays around for multiple device creations, then subsequent matchpathcon() calls will be a bit faster (although pathname regex matching is still going to take time). In any event, the patch to udev would naturally be #ifdef'd WITH_SELINUX, so no effect on non-SELinux users. Dan had a patch at one time, although I'm not sure that it used setfscreatecon(); it may have done a setfilecon() after creation. Preferable to use setfscreatecon() prior to creation, but either way is ok as long as you guarantee that no access is possible prior to labeling. -- 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: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn) Date: Mon, 2 Aug 2004 21:00:52 +0100
> On Mon, 2004-08-02 at 15:12, Luke Kenneth Casson Leighton wrote: great.
> In any event, the patch to udev would naturally be #ifdef'd and is_selinux_enabled() even :)
> Dan had a patch at one if it was the one that was in udev-0.024, it was setfilecon. it was taken out, along with the dbus patch, due to the amount of time that (both these patches) were perceived as hitting the system with. i mean, dbus was causing a ONE SECOND delay per device node. from what i can gather, i believe the selinux patch got painted with the same tar brush. l. -- 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: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn) Date: Mon, 2 Aug 2004 22:25:20 +0100
_and_ directories. darn. l. -- -- Information I post is with honesty, integrity, and the expectation that you will take full responsibility if acting on the information contained, and that, should you find it to be flawed or even mildly useful, you will act with both honesty and integrity in return - and tell me. --From: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn) Date: Mon, 2 Aug 2004 22:12:12 +0100
> On Mon, 2004-08-02 at 15:12, Luke Kenneth Casson Leighton wrote: okay, quick question: if i use setfscreatecon(), is it a "one-time" create, or is it effective on all creates up until the time that freecon() is called? [because if it's "up until freecon() is called", then the bug that the selinux patch to udev was suffering from was that free(scontext) was being used instead of freecon().] oops ;) l. p.s. first cut at mods attached for general review NO I HAVEN'T COMPILED IT.
-- 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: matchfilecon (the program) vs matchfilecon (the libselinux1 fn) Date: Tue, 03 Aug 2004 07:11:32 -0400
Once set, the fscreate context remains set for all file creations until the program explicitly resets it (via another setfscreatecon() call) or the program performs an execve (in which case the context is reset so that all programs start in a known state, defaulting to the policy-defined labeling behavior). The freecon() is irrelevant to the "lifetime" of the fscreate context, as it just frees the context in the application's memory; it doesn't affect the saved value for the task in the kernel.
> [because if it's "up until freecon() is called", then the bug that While it is preferable to use freecon() for encapsulation, it is presently true that freecon(x) == free(x). With regard to your patch, please pass the actual mode to matchpathcon, not 0, as the second parameter. This allows the matching to take into account the file type, e.g. whether it is a character device or a block device. -- 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: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn) Date: Tue, 3 Aug 2004 14:37:55 +0100
eek okay so i should use getcon() and restore the context afterwards.
> The freecon() is irrelevant to the ack.
> > [because if it's "up until freecon() is called", then the bug that oh yeah i forgot. l. -- 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: matchfilecon (the program) vs matchfilecon (the libselinux1 fn) Date: Fri, 6 Aug 2004 22:05:08 +1000
udev is tricky in this regard because there is the possibility that udev may be started before SE Linux is enabled. Maybe the best thing to do would be to check for SE Linux being enabled once for each group of new devices that you add, and only once for the system startup. -- 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: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn) Date: Sat, 7 Aug 2004 13:23:10 +0100
ee! okay.
> udev is tricky in this regard because there is the possibility that udev may ... for my purposes i am happy to assume that this not be the case. l. -- 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: Luke Kenneth Casson Leighton <lkcl_at_lkcl.net> subject: Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn) Date: Mon, 2 Aug 2004 21:10:16 +0100
this would probably explain why the selinux support in udev-024 was so slow: it was a separate program with functionality pretty much identical to /sbin/restorecon. l. -- 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 |