matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Luke Kenneth Casson Leighton]

hi,

does anyone know: the matchfilecon program reads
/etc/selinux/.../file_contexts/file_contexts.

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
/usr/share/selinux/stuff off of /usr and onto /etc.

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.

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Stephen Smalley]

On Sun, 2004-08-01 at 13:27, Luke Kenneth Casson Leighton wrote:
> hi,
> 
> does anyone know: the matchfilecon program reads
> /etc/selinux/.../file_contexts/file_contexts.
> 
> 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
> /usr/share/selinux/stuff off of /usr and onto /etc.

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.

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Stephen Smalley]

On Mon, 2004-08-02 at 10:57, Luke Kenneth Casson Leighton wrote:
>  ... 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.

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.

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Luke Kenneth Casson Leighton]

On Mon, Aug 02, 2004 at 10:00:23AM -0400, Stephen Smalley wrote:
> On Sun, 2004-08-01 at 13:27, Luke Kenneth Casson Leighton wrote:
> > hi,
> > 
> > does anyone know: the matchfilecon program reads
> > /etc/selinux/.../file_contexts/file_contexts.
> > 
> > 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
> > /usr/share/selinux/stuff off of /usr and onto /etc.
> 
> Do you mean matchpathcon?  

 yes.

> 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.  

 ack, ta.

> 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.

 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.

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Stephen Smalley]

On Mon, 2004-08-02 at 10:52, Stephen Smalley wrote:
> What's the objection to patching udev to directly invoke matchpathcon(3)
> and setfscreatecon(3) prior to creating each device node?

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.

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Luke Kenneth Casson Leighton]

On Mon, Aug 02, 2004 at 10:52:05AM -0400, Stephen Smalley wrote:
> On Mon, 2004-08-02 at 10:57, Luke Kenneth Casson Leighton wrote:
> >  ... 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.
> 
> What's the objection to patching udev to directly invoke matchpathcon(3)
> and setfscreatecon(3) prior to creating each device node?
 
 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.

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Stephen Smalley]

On Mon, 2004-08-02 at 15:12, Luke Kenneth Casson Leighton wrote:
> On Mon, Aug 02, 2004 at 10:52:05AM -0400, Stephen Smalley wrote:
> > What's the objection to patching udev to directly invoke matchpathcon(3)
> > and setfscreatecon(3) prior to creating each device node?
>  
>  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 (!!)

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.

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Luke Kenneth Casson Leighton]

On Mon, Aug 02, 2004 at 03:19:16PM -0400, Stephen Smalley wrote:

> On Mon, 2004-08-02 at 15:12, Luke Kenneth Casson Leighton wrote:
> > On Mon, Aug 02, 2004 at 10:52:05AM -0400, Stephen Smalley wrote:
> > > What's the objection to patching udev to directly invoke matchpathcon(3)
> > > and setfscreatecon(3) prior to creating each device node?
> >  
> >  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 (!!)
> 
> 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).

 great.

> In any event, the patch to udev would naturally be #ifdef'd
> WITH_SELINUX, so no effect on non-SELinux users.  

 and is_selinux_enabled() even :)


> 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.
 
 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.

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Luke Kenneth Casson Leighton]

On Mon, Aug 02, 2004 at 03:19:16PM -0400, Stephen Smalley wrote:
> On Mon, 2004-08-02 at 15:12, Luke Kenneth Casson Leighton wrote:
> > On Mon, Aug 02, 2004 at 10:52:05AM -0400, Stephen Smalley wrote:
> > > What's the objection to patching udev to directly invoke matchpathcon(3)
> > > and setfscreatecon(3) prior to creating each device node?
> >  
> >  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 (!!)
> 
> 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).
 
 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.

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Luke Kenneth Casson Leighton]

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

On Mon, Aug 02, 2004 at 03:19:16PM -0400, Stephen Smalley wrote:

> On Mon, 2004-08-02 at 15:12, Luke Kenneth Casson Leighton wrote:
> > On Mon, Aug 02, 2004 at 10:52:05AM -0400, Stephen Smalley wrote:
> > > What's the objection to patching udev to directly invoke matchpathcon(3)
> > > and setfscreatecon(3) prior to creating each device node?
> >  
> >  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 (!!)
> 
> 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).

 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.

[-- Attachment #2: f --]
[-- Type: text/plain, Size: 2265 bytes --]

--- udev-add.c.orig	2004-07-09 18:59:09.000000000 +0100
+++ udev-add.c	2004-08-02 22:10:50.000000000 +0100
@@ -50,6 +50,10 @@
 
 #define LOCAL_USER "$local"
 
+#ifdef WITH_SELINUX
+#include <selinux/selinux.h>
+#endif
+
 /* 
  * Right now the major/minor of a device is stored in a file called
  * "dev" in sysfs.
@@ -109,6 +113,10 @@
 {
 	struct stat stats;
 	int retval = 0;
+	int seretval = 0;
+#ifdef WITH_SELINUX
+	security_context_t scontext;
+#endif
 
 	if (stat(file, &stats) != 0)
 		goto create;
@@ -117,6 +125,24 @@
 	if (((stats.st_mode & S_IFMT) == S_IFBLK || (stats.st_mode & S_IFMT) == S_IFCHR) &&
 	    (stats.st_rdev == makedev(major, minor))) {
 		dbg("preserve file '%s', cause it has correct dev_t", file);
+#ifdef WITH_SELINUX
+		/* lkcl: maybe someone would like to do the same thing with se/linux
+		 * security contexts (check they are the same) but hey, not me!
+		 */
+	   if (is_selinux_enabled() > 0)
+	   {
+			retval = matchpathcon(file, 0, &scontext);
+			if (retval < 0) {
+				dbg("matchpathcon(%s) failed\n", file);
+			} else {
+				retval=setfilecon(scontext, file);
+				if (retval < 0)
+					dbg("setfiles %s failed with error '%s'",
+				filename, strerror(errno));
+				freecon(scontext);
+			}
+		}
+#endif
 		goto perms;
 	}
 
@@ -126,6 +152,21 @@
 		dbg("already present file '%s' unlinked", file);
 
 create:
+#ifdef WITH_SELINUX
+   if (is_selinux_enabled() > 0)
+   {
+		seretval = matchpathcon(filename, 0, &scontext);
+		if (seretval < 0) {
+			dbg("matchpathcon(%s) failed\n", filename);
+		} else {
+			retval=setfscreatecon(scontext);
+			if (retval < 0)
+				dbg("setfiles %s failed with error '%s'",
+			filename, strerror(errno));
+		}
+	}
+#endif
+						    
 	retval = mknod(file, mode, makedev(major, minor));
 	if (retval != 0) {
 		dbg("mknod(%s, %#o, %u, %u) failed with error '%s'",
@@ -133,6 +174,15 @@
 		goto exit;
 	}
 
+#ifdef WITH_SELINUX
+   if (is_selinux_enabled() > 0)
+   {
+	   /* after mknod, free the context */
+		if (seretval == 0)
+			freecon(scontext);
+	}
+#endif
+						    
 perms:
 	dbg("chmod(%s, %#o)", file, mode);
 	if (chmod(file, mode) != 0) {
@@ -150,7 +200,7 @@
 	}
 
 exit:
-	return retval;
+	return retval < 0 ? retval : seretval;
 }
 
 /* get the local logged in user */

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Luke Kenneth Casson Leighton]

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

On Mon, Aug 02, 2004 at 03:19:16PM -0400, Stephen Smalley wrote:

> On Mon, 2004-08-02 at 15:12, Luke Kenneth Casson Leighton wrote:
> > On Mon, Aug 02, 2004 at 10:52:05AM -0400, Stephen Smalley wrote:
> > > What's the objection to patching udev to directly invoke matchpathcon(3)
> > > and setfscreatecon(3) prior to creating each device node?
> >  
> >  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 (!!)
> 
> 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).

 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.

[-- Attachment #2: f --]
[-- Type: text/plain, Size: 2265 bytes --]

--- udev-add.c.orig	2004-07-09 18:59:09.000000000 +0100
+++ udev-add.c	2004-08-02 22:10:50.000000000 +0100
@@ -50,6 +50,10 @@
 
 #define LOCAL_USER "$local"
 
+#ifdef WITH_SELINUX
+#include <selinux/selinux.h>
+#endif
+
 /* 
  * Right now the major/minor of a device is stored in a file called
  * "dev" in sysfs.
@@ -109,6 +113,10 @@
 {
 	struct stat stats;
 	int retval = 0;
+	int seretval = 0;
+#ifdef WITH_SELINUX
+	security_context_t scontext;
+#endif
 
 	if (stat(file, &stats) != 0)
 		goto create;
@@ -117,6 +125,24 @@
 	if (((stats.st_mode & S_IFMT) == S_IFBLK || (stats.st_mode & S_IFMT) == S_IFCHR) &&
 	    (stats.st_rdev == makedev(major, minor))) {
 		dbg("preserve file '%s', cause it has correct dev_t", file);
+#ifdef WITH_SELINUX
+		/* lkcl: maybe someone would like to do the same thing with se/linux
+		 * security contexts (check they are the same) but hey, not me!
+		 */
+	   if (is_selinux_enabled() > 0)
+	   {
+			retval = matchpathcon(file, 0, &scontext);
+			if (retval < 0) {
+				dbg("matchpathcon(%s) failed\n", file);
+			} else {
+				retval=setfilecon(scontext, file);
+				if (retval < 0)
+					dbg("setfiles %s failed with error '%s'",
+				filename, strerror(errno));
+				freecon(scontext);
+			}
+		}
+#endif
 		goto perms;
 	}
 
@@ -126,6 +152,21 @@
 		dbg("already present file '%s' unlinked", file);
 
 create:
+#ifdef WITH_SELINUX
+   if (is_selinux_enabled() > 0)
+   {
+		seretval = matchpathcon(filename, 0, &scontext);
+		if (seretval < 0) {
+			dbg("matchpathcon(%s) failed\n", filename);
+		} else {
+			retval=setfscreatecon(scontext);
+			if (retval < 0)
+				dbg("setfiles %s failed with error '%s'",
+			filename, strerror(errno));
+		}
+	}
+#endif
+						    
 	retval = mknod(file, mode, makedev(major, minor));
 	if (retval != 0) {
 		dbg("mknod(%s, %#o, %u, %u) failed with error '%s'",
@@ -133,6 +174,15 @@
 		goto exit;
 	}
 
+#ifdef WITH_SELINUX
+   if (is_selinux_enabled() > 0)
+   {
+	   /* after mknod, free the context */
+		if (seretval == 0)
+			freecon(scontext);
+	}
+#endif
+						    
 perms:
 	dbg("chmod(%s, %#o)", file, mode);
 	if (chmod(file, mode) != 0) {
@@ -150,7 +200,7 @@
 	}
 
 exit:
-	return retval;
+	return retval < 0 ? retval : seretval;
 }
 
 /* get the local logged in user */

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Luke Kenneth Casson Leighton]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

p.s. setting permissions on symlinks was missed out, too.

_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.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


[-- Attachment #2: f --]
[-- Type: text/plain, Size: 4619 bytes --]

--- Makefile.orig	2004-08-02 22:23:58.000000000 +0100
+++ Makefile	2004-08-02 22:24:01.000000000 +0100
@@ -25,6 +25,8 @@
 # Leave this set to `false' for production use.
 DEBUG = true
 
+# Set this to compile with Security-Enhanced Linux support.
+WITH_SELINUX = true
 
 ROOT =		udev
 DAEMON =	udevd
@@ -39,6 +41,7 @@
 LOCAL_CFG_DIR =	etc/udev
 HOTPLUG_EXEC =	$(ROOT)
 
+
 DESTDIR =
 
 KERNEL_DIR = /lib/modules/${shell uname -r}/build
@@ -172,6 +175,13 @@
 
 CFLAGS += -I$(PWD)/libsysfs
 
+ifeq ($(strip $(WITH_SELINUX)),true)
+	LIB_OBJS +=	\
+			-lselinux
+	CFLAGS += \
+		-DWITH_SELINUX
+endif
+
 all: $(ROOT) $(SENDER) $(DAEMON) $(INFO) $(TESTER) $(STARTER)
 	@extras="$(EXTRAS)" ; for target in $$extras ; do \
 		echo $$target ; \
--- udev-add.c.orig	2004-07-09 18:59:09.000000000 +0100
+++ udev-add.c	2004-08-02 22:23:27.000000000 +0100
@@ -50,6 +50,10 @@
 
 #define LOCAL_USER "$local"
 
+#ifdef WITH_SELINUX
+#include <selinux/selinux.h>
+#endif
+
 /* 
  * Right now the major/minor of a device is stored in a file called
  * "dev" in sysfs.
@@ -92,7 +96,31 @@
 			break;
 		*pos = 0x00;
 		if (stat(p, &stats)) {
+#ifdef WITH_SELINUX
+			int seretval = 0;
+			security_context_t scontext;
+		   if (is_selinux_enabled() > 0)
+		   {
+				seretval = matchpathcon(p, 0, &scontext);
+				if (seretval < 0) {
+					dbg("matchpathcon(%s) failed\n", p);
+				} else {
+					seretval=setfscreatecon(scontext);
+					if (seretval < 0)
+						dbg("setfiles %s failed with error '%s'",
+					p, strerror(errno));
+				}
+			}
+#endif
 			retval = mkdir(p, 0755);
+#ifdef WITH_SELINUX
+			if (is_selinux_enabled() > 0)
+			{
+			   /* after mkdir, free the context */
+				freecon(scontext);
+			}
+#endif
+									
 			if (retval != 0) {
 				dbg("mkdir(%s) failed with error '%s'",
 				    p, strerror(errno));
@@ -109,6 +137,10 @@
 {
 	struct stat stats;
 	int retval = 0;
+	int seretval = 0;
+#ifdef WITH_SELINUX
+	security_context_t scontext;
+#endif
 
 	if (stat(file, &stats) != 0)
 		goto create;
@@ -117,6 +149,24 @@
 	if (((stats.st_mode & S_IFMT) == S_IFBLK || (stats.st_mode & S_IFMT) == S_IFCHR) &&
 	    (stats.st_rdev == makedev(major, minor))) {
 		dbg("preserve file '%s', cause it has correct dev_t", file);
+#ifdef WITH_SELINUX
+		/* lkcl: maybe someone would like to do the same thing with se/linux
+		 * security contexts (check they are the same) but hey, not me!
+		 */
+	   if (is_selinux_enabled() > 0)
+	   {
+			retval = matchpathcon(file, 0, &scontext);
+			if (retval < 0) {
+				dbg("matchpathcon(%s) failed\n", file);
+			} else {
+				retval=setfilecon(scontext, file);
+				if (retval < 0)
+					dbg("setfiles %s failed with error '%s'",
+				file, strerror(errno));
+				freecon(scontext);
+			}
+		}
+#endif
 		goto perms;
 	}
 
@@ -126,6 +176,21 @@
 		dbg("already present file '%s' unlinked", file);
 
 create:
+#ifdef WITH_SELINUX
+   if (is_selinux_enabled() > 0)
+   {
+		seretval = matchpathcon(file, 0, &scontext);
+		if (seretval < 0) {
+			dbg("matchpathcon(%s) failed\n", file);
+		} else {
+			retval=setfscreatecon(scontext);
+			if (retval < 0)
+				dbg("setfiles %s failed with error '%s'",
+			file, strerror(errno));
+		}
+	}
+#endif
+						    
 	retval = mknod(file, mode, makedev(major, minor));
 	if (retval != 0) {
 		dbg("mknod(%s, %#o, %u, %u) failed with error '%s'",
@@ -133,6 +198,15 @@
 		goto exit;
 	}
 
+#ifdef WITH_SELINUX
+   if (is_selinux_enabled() > 0)
+   {
+	   /* after mknod, free the context */
+		if (seretval == 0)
+			freecon(scontext);
+	}
+#endif
+						    
 perms:
 	dbg("chmod(%s, %#o)", file, mode);
 	if (chmod(file, mode) != 0) {
@@ -150,7 +224,7 @@
 	}
 
 exit:
-	return retval;
+	return retval < 0 ? retval : seretval;
 }
 
 /* get the local logged in user */
@@ -304,10 +378,36 @@
 
 		dbg("symlink(%s, %s)", linktarget, filename);
 		if (!fake) {
+#ifdef WITH_SELINUX
+			int seretval = 0;
+			security_context_t scontext;
+		   if (is_selinux_enabled() > 0)
+		   {
+				seretval = matchpathcon(filename, 0, &scontext);
+				if (seretval < 0) {
+					dbg("matchpathcon(%s) failed\n", filename);
+				} else {
+					seretval=setfscreatecon(scontext);
+					if (seretval < 0)
+						dbg("setfiles %s failed with error '%s'",
+					filename, strerror(errno));
+				}
+			}
+#endif
+									
+
 			unlink(filename);
 			if (symlink(linktarget, filename) != 0)
 				dbg("symlink(%s, %s) failed with error '%s'",
 				    linktarget, filename, strerror(errno));
+#ifdef WITH_SELINUX
+		   if (is_selinux_enabled() > 0)
+		   {
+			   /* after symlink, free the context */
+				freecon(scontext);
+			}
+#endif
+									
 		}
 	}
 

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Luke Kenneth Casson Leighton]

[-- Attachment #1: Type: text/plain, Size: 499 bytes --]

p.s. setting permissions on symlinks was missed out, too.

_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.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


[-- Attachment #2: f --]
[-- Type: text/plain, Size: 4619 bytes --]

--- Makefile.orig	2004-08-02 22:23:58.000000000 +0100
+++ Makefile	2004-08-02 22:24:01.000000000 +0100
@@ -25,6 +25,8 @@
 # Leave this set to `false' for production use.
 DEBUG = true
 
+# Set this to compile with Security-Enhanced Linux support.
+WITH_SELINUX = true
 
 ROOT =		udev
 DAEMON =	udevd
@@ -39,6 +41,7 @@
 LOCAL_CFG_DIR =	etc/udev
 HOTPLUG_EXEC =	$(ROOT)
 
+
 DESTDIR =
 
 KERNEL_DIR = /lib/modules/${shell uname -r}/build
@@ -172,6 +175,13 @@
 
 CFLAGS += -I$(PWD)/libsysfs
 
+ifeq ($(strip $(WITH_SELINUX)),true)
+	LIB_OBJS +=	\
+			-lselinux
+	CFLAGS += \
+		-DWITH_SELINUX
+endif
+
 all: $(ROOT) $(SENDER) $(DAEMON) $(INFO) $(TESTER) $(STARTER)
 	@extras="$(EXTRAS)" ; for target in $$extras ; do \
 		echo $$target ; \
--- udev-add.c.orig	2004-07-09 18:59:09.000000000 +0100
+++ udev-add.c	2004-08-02 22:23:27.000000000 +0100
@@ -50,6 +50,10 @@
 
 #define LOCAL_USER "$local"
 
+#ifdef WITH_SELINUX
+#include <selinux/selinux.h>
+#endif
+
 /* 
  * Right now the major/minor of a device is stored in a file called
  * "dev" in sysfs.
@@ -92,7 +96,31 @@
 			break;
 		*pos = 0x00;
 		if (stat(p, &stats)) {
+#ifdef WITH_SELINUX
+			int seretval = 0;
+			security_context_t scontext;
+		   if (is_selinux_enabled() > 0)
+		   {
+				seretval = matchpathcon(p, 0, &scontext);
+				if (seretval < 0) {
+					dbg("matchpathcon(%s) failed\n", p);
+				} else {
+					seretval=setfscreatecon(scontext);
+					if (seretval < 0)
+						dbg("setfiles %s failed with error '%s'",
+					p, strerror(errno));
+				}
+			}
+#endif
 			retval = mkdir(p, 0755);
+#ifdef WITH_SELINUX
+			if (is_selinux_enabled() > 0)
+			{
+			   /* after mkdir, free the context */
+				freecon(scontext);
+			}
+#endif
+									
 			if (retval != 0) {
 				dbg("mkdir(%s) failed with error '%s'",
 				    p, strerror(errno));
@@ -109,6 +137,10 @@
 {
 	struct stat stats;
 	int retval = 0;
+	int seretval = 0;
+#ifdef WITH_SELINUX
+	security_context_t scontext;
+#endif
 
 	if (stat(file, &stats) != 0)
 		goto create;
@@ -117,6 +149,24 @@
 	if (((stats.st_mode & S_IFMT) == S_IFBLK || (stats.st_mode & S_IFMT) == S_IFCHR) &&
 	    (stats.st_rdev == makedev(major, minor))) {
 		dbg("preserve file '%s', cause it has correct dev_t", file);
+#ifdef WITH_SELINUX
+		/* lkcl: maybe someone would like to do the same thing with se/linux
+		 * security contexts (check they are the same) but hey, not me!
+		 */
+	   if (is_selinux_enabled() > 0)
+	   {
+			retval = matchpathcon(file, 0, &scontext);
+			if (retval < 0) {
+				dbg("matchpathcon(%s) failed\n", file);
+			} else {
+				retval=setfilecon(scontext, file);
+				if (retval < 0)
+					dbg("setfiles %s failed with error '%s'",
+				file, strerror(errno));
+				freecon(scontext);
+			}
+		}
+#endif
 		goto perms;
 	}
 
@@ -126,6 +176,21 @@
 		dbg("already present file '%s' unlinked", file);
 
 create:
+#ifdef WITH_SELINUX
+   if (is_selinux_enabled() > 0)
+   {
+		seretval = matchpathcon(file, 0, &scontext);
+		if (seretval < 0) {
+			dbg("matchpathcon(%s) failed\n", file);
+		} else {
+			retval=setfscreatecon(scontext);
+			if (retval < 0)
+				dbg("setfiles %s failed with error '%s'",
+			file, strerror(errno));
+		}
+	}
+#endif
+						    
 	retval = mknod(file, mode, makedev(major, minor));
 	if (retval != 0) {
 		dbg("mknod(%s, %#o, %u, %u) failed with error '%s'",
@@ -133,6 +198,15 @@
 		goto exit;
 	}
 
+#ifdef WITH_SELINUX
+   if (is_selinux_enabled() > 0)
+   {
+	   /* after mknod, free the context */
+		if (seretval == 0)
+			freecon(scontext);
+	}
+#endif
+						    
 perms:
 	dbg("chmod(%s, %#o)", file, mode);
 	if (chmod(file, mode) != 0) {
@@ -150,7 +224,7 @@
 	}
 
 exit:
-	return retval;
+	return retval < 0 ? retval : seretval;
 }
 
 /* get the local logged in user */
@@ -304,10 +378,36 @@
 
 		dbg("symlink(%s, %s)", linktarget, filename);
 		if (!fake) {
+#ifdef WITH_SELINUX
+			int seretval = 0;
+			security_context_t scontext;
+		   if (is_selinux_enabled() > 0)
+		   {
+				seretval = matchpathcon(filename, 0, &scontext);
+				if (seretval < 0) {
+					dbg("matchpathcon(%s) failed\n", filename);
+				} else {
+					seretval=setfscreatecon(scontext);
+					if (seretval < 0)
+						dbg("setfiles %s failed with error '%s'",
+					filename, strerror(errno));
+				}
+			}
+#endif
+									
+
 			unlink(filename);
 			if (symlink(linktarget, filename) != 0)
 				dbg("symlink(%s, %s) failed with error '%s'",
 				    linktarget, filename, strerror(errno));
+#ifdef WITH_SELINUX
+		   if (is_selinux_enabled() > 0)
+		   {
+			   /* after symlink, free the context */
+				freecon(scontext);
+			}
+#endif
+									
 		}
 	}
 

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Stephen Smalley]

On Mon, 2004-08-02 at 17: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?

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
>   the selinux patch to udev was suffering from was that free(scontext)
>   was being used instead of freecon().]

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 SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Stephen Smalley]

On Mon, 2004-08-02 at 17: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?

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
>   the selinux patch to udev was suffering from was that free(scontext)
>   was being used instead of freecon().]

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.

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Luke Kenneth Casson Leighton]

On Tue, Aug 03, 2004 at 07:11:32AM -0400, Stephen Smalley wrote:
> On Mon, 2004-08-02 at 17: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?
> 
> 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).  

 eek okay so i should use getcon() and restore the context afterwards.


> 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.
 
  ack.

> >  [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().]
> 
> 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.

 oh yeah i forgot.

 l.



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Luke Kenneth Casson Leighton]

On Tue, Aug 03, 2004 at 07:11:32AM -0400, Stephen Smalley wrote:
> On Mon, 2004-08-02 at 17: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?
> 
> 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).  

 eek okay so i should use getcon() and restore the context afterwards.


> 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.
 
  ack.

> >  [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().]
> 
> 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.

 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.

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Russell Coker]

On Tue, 3 Aug 2004 07:12, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>  p.s. first cut at mods attached for general review NO I HAVEN'T
>  COMPILED IT.

One thing to note is that is_selinux_enabled() reads /proc/filesystems and 
then reads /proc/self/attr/current.  This is more work than you want to do 
for every device node.  So you want to cache the result of 
is_selinux_enabled() to some degree.  You certainly don't want to call it 
twice in the same code path.

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 SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Russell Coker]

On Tue, 3 Aug 2004 07:12, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>  p.s. first cut at mods attached for general review NO I HAVEN'T
>  COMPILED IT.

One thing to note is that is_selinux_enabled() reads /proc/filesystems and 
then reads /proc/self/attr/current.  This is more work than you want to do 
for every device node.  So you want to cache the result of 
is_selinux_enabled() to some degree.  You certainly don't want to call it 
twice in the same code path.

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.

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Luke Kenneth Casson Leighton]

On Fri, Aug 06, 2004 at 10:05:08PM +1000, Russell Coker wrote:
> On Tue, 3 Aug 2004 07:12, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> >  p.s. first cut at mods attached for general review NO I HAVEN'T
> >  COMPILED IT.
> 
> One thing to note is that is_selinux_enabled() reads /proc/filesystems and 
> then reads /proc/self/attr/current.  This is more work than you want to do 
> for every device node.  So you want to cache the result of 
> is_selinux_enabled() to some degree.  You certainly don't want to call it 
> twice in the same code path.
 
 ee!  okay.

> udev is tricky in this regard because there is the possibility that udev may 
> be started before SE Linux is enabled.

 ... for my purposes i am happy to assume that this not be the case.

 l.



-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: matchfilecon (the program) vs matchfilecon (the libselinux1 fn)

[Luke Kenneth Casson Leighton]

On Fri, Aug 06, 2004 at 10:05:08PM +1000, Russell Coker wrote:
> On Tue, 3 Aug 2004 07:12, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> >  p.s. first cut at mods attached for general review NO I HAVEN'T
> >  COMPILED IT.
> 
> One thing to note is that is_selinux_enabled() reads /proc/filesystems and 
> then reads /proc/self/attr/current.  This is more work than you want to do 
> for every device node.  So you want to cache the result of 
> is_selinux_enabled() to some degree.  You certainly don't want to call it 
> twice in the same code path.
 
 ee!  okay.

> udev is tricky in this regard because there is the possibility that udev may 
> be started before SE Linux is enabled.

 ... 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.