http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Luke Kenneth Casson Leighton]

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

hiya russell,

regarding the conversation with the upstream author, it
appears that he's expecting a response from you about some
issues with SYSUSERNAME and also with some apparent gcc niggle.

section cut/paste here:

  	if (syscron_stat.st_mtime) {
	> +#ifdef CONFIG_FLASK
	> +		process_crontab("root", SYSUSERNAME,
	> +#else
	>  		process_crontab("root", "*system*",
	> +#endif
	>  				SYSCRONTAB, &syscron_stat,
	>  				&new_db, old_db);
	>  	}

	See, this is still wrong. I asked Russell about it,
	but never got an answer (or I lost it, or never
	sent it, or something; it's not in my mail archive,
	anyway.). To re-iterate: "*system*" is not a username,
	it simply a string used to distinguish user crontabs
	(/var/spool/cron/*) from system crontabs (/etc/crontab,
	/etc/cron.d/*). The only importance is that not be a
	valid user name.

and i note that SYSUSERNAME is #defined to "system_u" in
cron.h

i take it that this is a more "informative" string
than "*system*" but it is equally as non-username-ish
as "*system*" is.

*thinks*....

... i think the patch to cron is wrong: i believe it should be this:

@@ -199,7 +208,11 @@
	continue;

	/* Generate the "fname" */
+#ifdef WITH_SELINUX
+       (void) strcpy(fname, SYSUSERNAME);
+#else
	(void) strcpy(fname,"*system*");
+#endif
	(void) strcat(fname, dp->d_name);
	sprintf(tabname,"%s/%s", SYSCRONDIR, dp->d_name);

@@ -324,6 +337,14 @@

the "fake" name created therefore contains information useful
to SELinux users whilst at the same time maintaining compatibility
with the purpose behind "*system*".

the original patch accidentally changed the behaviour of cron because
of the detection strcmp("*system",..) further on.

NB FOR ALL CRON USERS!!!

l.

-- 
-- 
expecting email to be received and understood is a bit like
picking up the telephone and immediately dialing without
checking for a dial-tone; speaking immediately without listening
for either an answer or ring-tone; hanging up immediately and
believing that you have actually started a conversation.
--
<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: 7950 bytes --]

diff -ru orig/cron-3.0pl1.orig/Makefile cron-3.0pl1/Makefile
--- orig/cron-3.0pl1.orig/Makefile	2004-05-19 09:10:08.000000000 +0000
+++ cron-3.0pl1/Makefile	2004-05-19 09:06:41.000000000 +0000
@@ -52,10 +52,10 @@
 DESTBIN		=	$(DESTROOT)/bin
 DESTMAN		=	$(DESTROOT)/share/man
 #<<need bitstring.h>>
-INCLUDE		=	-I.
+INCLUDE		=	-I. -I/usr/include/selinux
 #INCLUDE	=
 #<<need getopt()>>
-LIBS		= $(PAM_LIBS)
+LIBS		= $(PAM_LIBS) -lselinux
 #<<optimize or debug?>>
 OPTIM		=	-O2
 #OPTIM		=	-g
@@ -74,7 +74,7 @@
 # Allow override from command line
 DEBUG_DEFS = -DDEBUGGING=0   
 # The -DUSE_SIGCHLD is needed for the Alpha port
-DEFS = -DDEBIAN -DUSE_SIGCHLD $(DEBUG_DEFS) $(PAM_DEFS)
+DEFS = -DDEBIAN -DUSE_SIGCHLD $(DEBUG_DEFS) $(PAM_DEFS) -DWITH_SELINUX
 #(SGI IRIX systems need this)
 #DEFS		=	-D_BSD_SIGNALS -Dconst=
 #<<the name of the BSD-like install program>>
diff -ru orig/cron-3.0pl1.orig/config.h cron-3.0pl1/config.h
--- orig/cron-3.0pl1.orig/config.h	2004-05-19 09:10:08.000000000 +0000
+++ cron-3.0pl1/config.h	2004-05-19 09:06:41.000000000 +0000
@@ -43,7 +43,7 @@
 			 */
 
 #define MAILCMD _PATH_SENDMAIL					/*-*/
-/* #define MAILARGS "%s -i -FCronDaemon -odi -oem  %s"		/*-*/
+/* #define MAILARGS "%s -i -FCronDaemon -odi -oem  %s"		-*/
 #define MAILARGS "%s -i -FCronDaemon -oem  %s"		/*-*/
 			/* -i    = don't terminate on "." by itself
                          * -Fx	 = set full-name of sender
diff -ru orig/cron-3.0pl1.orig/cron.h cron-3.0pl1/cron.h
--- orig/cron-3.0pl1.orig/cron.h	2004-05-19 09:10:08.000000000 +0000
+++ cron-3.0pl1/cron.h	2004-05-19 09:06:41.000000000 +0000
@@ -40,6 +40,10 @@
 #include "config.h"
 #include "externs.h"
 
+#ifdef WITH_SELINUX 
+#define SYSUSERNAME "system_u"
+#endif
+
 	/* these are really immutable, and are
 	 *   defined for symbolic convenience only
 	 * TRUE, FALSE, and ERR must be distinct
Only in cron-3.0pl1/: cron.h.old
diff -ru orig/cron-3.0pl1.orig/database.c cron-3.0pl1/database.c
--- orig/cron-3.0pl1.orig/database.c	2004-05-19 09:10:08.000000000 +0000
+++ cron-3.0pl1/database.c	2004-05-19 09:08:13.000000000 +0000
@@ -30,6 +30,11 @@
 #include <sys/stat.h>
 #include <sys/file.h>
 
+#ifdef WITH_SELINUX
+#include <selinux/selinux.h>
+#include <selinux/flask.h>
+#include <selinux/av_permissions.h>
+#endif
 
 #define TMAX(a,b) ((a)>(b)?(a):(b))
 
@@ -167,7 +172,11 @@
 	new_db.head = new_db.tail = NULL;
 
 	if (syscron_stat.st_mtime) {
+#ifdef WITH_SELINUX
+		process_crontab("root", SYSUSERNAME,
+#else
 		process_crontab("root", "*system*",
+#endif
 				SYSCRONTAB, &syscron_stat,
 				&new_db, old_db);
 	}
@@ -199,7 +208,11 @@
 		  continue;
 
 		/* Generate the "fname" */
+#ifdef WITH_SELINUX
+		(void) strcpy(fname, SYSUSERNAME);
+#else
 		(void) strcpy(fname,"*system*");
+#endif
 		(void) strcat(fname, dp->d_name);
 		sprintf(tabname,"%s/%s", SYSCRONDIR, dp->d_name);
 
@@ -324,6 +337,14 @@
 	int		crontab_fd = OK - 1;
 	user		*u;
 
+#ifdef WITH_SELINUX
+	security_context_t  file_context=NULL;
+	security_context_t   user_context=NULL;
+	struct av_decision avd;
+	int retval=0, selinux_enabled = is_selinux_enabled();
+
+	if (strcmp(fname, SYSUSERNAME) && !(pw = getpwnam(uname))) {
+#else
 #ifdef DEBIAN
 	/* If the name begins with *system*, don't worry about password -
 	 it's part of the system crontab */
@@ -331,6 +352,7 @@
 #else
 	if (strcmp(fname, "*system*") && !(pw = getpwnam(uname))) {
 #endif
+#endif
 		/* file doesn't have a user in passwd file.
 		 */
 		if (strncmp(fname, "tmp.", 4)) {
@@ -349,6 +371,14 @@
 		goto next_crontab;
             }
 
+#ifdef WITH_SELINUX
+	    if (selinux_enabled) {
+		if (fgetfilecon(crontab_fd, &file_context) < OK) {
+		    log_it(fname, getpid(), "getfilecon FAILED", tabname);
+		    goto next_crontab;
+		}
+	    }
+#endif
             if (fstat(crontab_fd, statbuf) < OK) {
 		log_it(fname, getpid(), "FSTAT FAILED", tabname);
 		goto next_crontab;
@@ -385,6 +415,14 @@
 		goto next_crontab;
             }
 
+#ifdef WITH_SELINUX
+	    if (selinux_enabled) {
+		if (fgetfilecon(crontab_fd, &file_context) < OK) {
+		    log_it(fname, getpid(), "getfilecon FAILED", tabname);
+		    goto next_crontab;
+		}
+	    }
+#endif
             if (fstat(crontab_fd, statbuf) < OK) {
 		log_it(fname, getpid(), "FSTAT FAILED", tabname);
 		goto next_crontab;
@@ -425,6 +463,31 @@
 		free_user(u);
 		log_it(fname, getpid(), "RELOAD", tabname);
 	}
+#ifdef WITH_SELINUX
+	if (selinux_enabled)	{
+		/*
+		 * Since crontab files are not directly executed,
+		 * crond must ensure that the crontab file has
+		 * a context that is appropriate for the context of
+		 * the user cron job.  It performs an entrypoint
+		 * permission check for this purpose.
+		 */
+		if (get_default_context(fname, NULL, &user_context)) {
+			log_it(fname, getpid(), "NO CONTEXT", tabname);
+			goto next_crontab;
+		}
+		retval = security_compute_av(user_context, file_context,
+			SECCLASS_FILE, FILE__ENTRYPOINT, &avd);
+		freecon(user_context);
+		freecon(file_context);
+		file_context = NULL;
+
+		if (retval || ((FILE__ENTRYPOINT & avd.allowed) != FILE__ENTRYPOINT)) {
+			log_it(fname, getpid(), "ENTRYPOINT FAILED", tabname);
+			goto next_crontab;
+		}
+	}
+#endif
 	u = load_user(crontab_fd, pw, fname);
 	if (u != NULL) {
 		u->mtime = statbuf->st_mtime;
@@ -436,6 +499,12 @@
 		Debug(DLOAD, (" [done]\n"))
 		close(crontab_fd);
 	}
+#ifdef WITH_SELINUX
+	if(file_context) {
+		freecon(file_context);
+		file_context = NULL;
+	}
+#endif
 }
 
 #ifdef DEBIAN
Only in cron-3.0pl1/: database.c.old
diff -ru orig/cron-3.0pl1.orig/debian/changelog cron-3.0pl1/debian/changelog
--- orig/cron-3.0pl1.orig/debian/changelog	2004-05-19 09:10:08.000000000 +0000
+++ cron-3.0pl1/debian/changelog	2004-05-19 09:06:42.000000000 +0000
@@ -1,3 +1,9 @@
+cron (3.0pl1-83.se1) unstable; urgency=low
+
+  * Built with new SE Linux support.
+
+ -- Russell Coker <russell@coker.com.au>  Fri, 23 Jan 2004 13:58:00 +1100
+
 cron (3.0pl1-83) unstable; urgency=low
 
   * Update default MTA from exim to exim4 (closes:#228561)
diff -ru orig/cron-3.0pl1.orig/debian/control cron-3.0pl1/debian/control
--- orig/cron-3.0pl1.orig/debian/control	2004-05-19 09:10:08.000000000 +0000
+++ cron-3.0pl1/debian/control	2004-05-19 09:06:42.000000000 +0000
@@ -3,13 +3,13 @@
 Priority: important
 Maintainer: Steve Greenland <stevegr@debian.org>
 Standards-Version: 3.6.1
-Build-Depends: debhelper, libpam0g-dev
+Build-Depends: debhelper, libpam0g-dev, libselinux1-dev
 
 Package: cron
 Architecture: any
 Depends: ${shlibs:Depends}, debianutils (>=1.7), adduser
 Recommends: exim4 | postfix | mail-transport-agent
-Suggests: anacron (>=2.0-1), logrotate, lockfile-progs, checksecurity
+Suggests: anacron (>=2.0-1), logrotate, lockfile-progs
 Conflicts: suidmanager (<< 0.50), lockfile-progs (<< 0.1.7)
 Provides:
 Description: management of regular background processing
diff -ru orig/cron-3.0pl1.orig/do_command.c cron-3.0pl1/do_command.c
--- orig/cron-3.0pl1.orig/do_command.c	2004-05-19 09:10:08.000000000 +0000
+++ cron-3.0pl1/do_command.c	2004-05-19 09:06:42.000000000 +0000
@@ -42,6 +42,10 @@
    }
 #endif
 
+#ifdef WITH_SELINUX
+#include <selinux/selinux.h>
+#endif
+
 
 static void		child_process __P((entry *, user *)),
 			do_univ __P((user *));
@@ -323,6 +327,20 @@
 			}
 			fprintf(stdout,"error");
 #endif
+#ifdef WITH_SELINUX
+			if (is_selinux_enabled()) {
+			  security_context_t scontext;
+			  if (get_default_context(u->name, NULL, &scontext)) {
+			    fprintf(stderr, "execle_secure: couldn't get security context for user %s\n", u->name);
+			    _exit(ERROR_EXIT);
+			  }
+			  if (setexeccon(scontext) < 0) {
+			    fprintf(stderr, "Could not set exec context to %s for user  %s\n", scontext,u->name);
+			    _exit(ERROR_EXIT);
+			  }
+			  freecon(scontext);
+			}
+#endif
                         execle(shell, shell, "-c", e->cmd, (char *)0, jobenv);
 			fprintf(stderr, "execl: couldn't exec `%s'\n", shell);
 			perror("execl");

Re: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Stephen Smalley]

On Wed, 2004-05-19 at 05:14, Luke Kenneth Casson Leighton wrote:
> 	See, this is still wrong. I asked Russell about it,
> 	but never got an answer (or I lost it, or never
> 	sent it, or something; it's not in my mail archive,
> 	anyway.). To re-iterate: "*system*" is not a username,
> 	it simply a string used to distinguish user crontabs
> 	(/var/spool/cron/*) from system crontabs (/etc/crontab,
> 	/etc/cron.d/*). The only importance is that not be a
> 	valid user name.

We had an email exchange with Steve Greenland in September 2003 about
this issue, but it wasn't really resolved.  To summarize:

- We want to be able to run /etc/crontab and /etc/cron.d/* entries in a
different security context than user-configurable crontab entries (even
/var/spool/cron/crontabs/root), as the integrity of the former can be
locked down more tightly.  Under SELinux, root (uid 0) can't necessarily
modify the former.  If we use the user id from the /etc/crontab
configuration, then we would lose that distinction.  Using the existing
'*system*' indicator and mapping that to the SELinux system_u user
conveys the notion of system cron jobs transparently to SELinux for
obtaining an appropriate security context.  Unless /etc/crontab and
/etc/cron.d/* is used in some cases for real users (as opposed to root
and pseudo users for system jobs), there seems to be no point in
changing the SELinux patch in this respect.  Doing so would merely
require us to add such pseudo users to the SELinux policy, which isn't
desirable in most cases.

- We want to be able to bind the ability to run in a particular cron job
security context to the file security context on the crontab file, so
that we can prevent execution of commands from crontab files created by
less trustworthy domains in a more privileged domain.  Note that the
crontab program is run in a different domain depending on the caller's
domain, and that the resulting crontab file is created with an
appropriate type, so user_t can't create a crontab that will execute in
sysadm_crond_t.  The crond entrypoint permission check provides this
safeguard; it is emulating the kernel check that would be performed if
crontab files were directly executed.  If we were to change the SELinux
patch to use the user identity from /etc/crontab, then multiple distinct
user contexts would need entrypoint permission to a single crontab file
context.
 
> i take it that this is a more "informative" string
> than "*system*" but it is equally as non-username-ish
> as "*system*" is.

It conveys to the SELinux code that we want a security context
appropriate for system cron jobs transparently, as system_u is already
the SELinux user identity for system processes.  And it doesn't hurt
anything, as neither "*system*" nor "system_u" should exist in
/etc/passwd.

> the "fake" name created therefore contains information useful
> to SELinux users whilst at the same time maintaining compatibility
> with the purpose behind "*system*".
> 
> the original patch accidentally changed the behaviour of cron because
> of the detection strcmp("*system",..) further on.

The SELinux patch for cron changes all instances of "*system*" to
SYSUSERNAME, at least in Fedora.  I don't know about the Debian port of
the patch.  Please sync with the Fedora patch before merging, see
http://www.nsa.gov/selinux/patches/vixie-cron-selinux.patch.gz.

-- 
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: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Luke Kenneth Casson Leighton]

On Wed, May 19, 2004 at 09:30:53AM -0400, Stephen Smalley wrote:

> > i take it that this is a more "informative" string
> > than "*system*" but it is equally as non-username-ish
> > as "*system*" is.
> 
> It conveys to the SELinux code that we want a security context
> appropriate for system cron jobs transparently, as system_u is already
> the SELinux user identity for system processes.  And it doesn't hurt
> anything, as neither "*system*" nor "system_u" should exist in
> /etc/passwd.
 
  then the maintainer of debian crond needs to be authoritatively
  informed of this, as it will help reassure him that no damage is
  done by the change.

  in other words, what you are saying is that by putting system_u
  there instead, on the basis that no one is expected to add a
  user named "system_u" on a non-SELinux system, the change from
  "*system*" to "system_u" will have zero impact on a system
  that does not have an SELinux kernel.



> > the "fake" name created therefore contains information useful
> > to SELinux users whilst at the same time maintaining compatibility
> > with the purpose behind "*system*".
> > 
> > the original patch accidentally changed the behaviour of cron because
> > of the detection strcmp("*system",..) further on.
> 
> The SELinux patch for cron changes all instances of "*system*" to
> SYSUSERNAME, at least in Fedora.  I don't know about the Debian port of
> the patch.  Please sync with the Fedora patch before merging, see
> http://www.nsa.gov/selinux/patches/vixie-cron-selinux.patch.gz.
 

 okay.

 in the debian version of cron (3.0, at line 136 of database.c, the
 second argument to process_crontab is fname, which is a concatenation
 of "*system*" and some other information.

 this concatenation will of course make the strcmp against "*system*",
 at line 245, FAIL in the case where the 2nd arg to process_crontab
 is "*system*someotherinformation"

 this MAY just be a bug in the debian version of cron: i cannot tell
 because i do not know enough about it.


 however, i note with interest that the Fedora patch you mention above
 is against a vixie-cron where the 2nd argument to process_crontab
 is "*system" in BOTH calls to process_crontab, at lines 94 and 136
 of database.c.

 i can only point out the discrepancy between the Fedora vixie-cron
 and the Debian 3.0 cron (based on vixie-cron): i cannot make an informed
 statement about what is right.


 however, in the instance where the Fedora vixie cron happens to be
 correct, then the SELinux cron patch is fixing a bug.

 in the instance where the debian maintained version of cron 3.0
 is correct, then there is a bug in vixie cron which is being
 re-introduced by the Debian/SElinux cron patch.

 ... which is it?

 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: Bug#193644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Steve Greenland]

On 19-May-04, 09:02 (CDT), Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote: 
> On Wed, May 19, 2004 at 09:30:53AM -0400, Stephen Smalley wrote:
> 
> > > i take it that this is a more "informative" string
> > > than "*system*" but it is equally as non-username-ish
> > > as "*system*" is.
> > 
> > It conveys to the SELinux code that we want a security context
> > appropriate for system cron jobs transparently, as system_u is already
> > the SELinux user identity for system processes.  And it doesn't hurt
> > anything, as neither "*system*" nor "system_u" should exist in
> > /etc/passwd.
>  
>   then the maintainer of debian crond needs to be authoritatively
>   informed of this, as it will help reassure him that no damage is
>   done by the change.

I've been informed, I just don't buy it. The only thing that name
is used for is to generate "names" for the (internal) database, to
associate it with a particular entry in the list of crontabs, since the
file names are possibly in conflict with system usernames. The only
legitimate use for it is to look up entries in that list. It's *NOT* the
username associated with the crontab. You can't even use it directly,
because the while the "name" of the /etc/crontab entry is "*system*",
the names of the /etc/cron.d entries are "*system*/<filename>" (e.g.
/etc/cron.d/foo maps to "*system*/foo").

It feels very misleading and confusing to overload it that way, and I
don't see the difference between checking for "system_u" and "*system*".

Except that "system_u" *is* a valid username, therefore raising the
possiblity of conflict between /etc/crontab and the crontab of user
system_u.

The database entry (struct _user) has a field for username. That's where
this belongs. 

>  this concatenation will of course make the strcmp against "*system*",
>  at line 245, FAIL in the case where the 2nd arg to process_crontab
>  is "*system*someotherinformation"
> 
>  this MAY just be a bug in the debian version of cron: i cannot tell
>  because i do not know enough about it.

There's no strcmp at line 245 of the debian database.c. What you're
looking at (probably) is this, around line 327 (beginning of
process_crontab()):

#ifdef DEBIAN
    /* If the name begins with *system*, don't worry about password -
     it's part of the system crontab */
    if (strncmp(fname, "*system*", 8) && !(pw = getpwnam(uname))) {
#else
    if (strcmp(fname, "*system*") && !(pw = getpwnam(uname))) {
#endif


And will work fine no matter what "*system*" is (well, so long as it's 8
characters, and that's trivially fixed with a sizeof()).

>  is against a vixie-cron where the 2nd argument to process_crontab
>  is "*system" in BOTH calls to process_crontab, at lines 94 and 136
>  of database.c.
> 
>  i can only point out the discrepancy between the Fedora vixie-cron
>  and the Debian 3.0 cron (based on vixie-cron): i cannot make an informed
>  statement about what is right.

You need to keep the entries for /etc/crontab and /etc/cron.d/ seperate
or you won't be able to pick up changes in the files. That sounds like
a Fedora bug, but since I've not looked at that code recently, all I'll
say is that it's worth looking at.

Steve

-- 
Steve Greenland
    The irony is that Bill Gates claims to be making a stable operating
    system and Linus Torvalds claims to be trying to take over the
    world.       -- seen on the net

--
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: Bug#193644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Russell Coker]

On Thu, 20 May 2004 04:11, Steve Greenland <steveg@moregruel.net> wrote:
> It feels very misleading and confusing to overload it that way, and I
> don't see the difference between checking for "system_u" and "*system*".
>
> Except that "system_u" *is* a valid username, therefore raising the
> possiblity of conflict between /etc/crontab and the crontab of user
> system_u.

If you are using SE Linux then a user name of "system_u" is not going to 
work, /bin/login etc can't launch shells with system_u as the identity.

I guess we can have the SE Linux code in crond know that "*system*" means that 
the identity of "system_u" should be used.

-- 
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: Bug#193644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Luke Kenneth Casson Leighton]

On Thu, May 20, 2004 at 06:00:46AM +1000, Russell Coker wrote:
> On Thu, 20 May 2004 04:11, Steve Greenland <steveg@moregruel.net> wrote:
> > It feels very misleading and confusing to overload it that way, and I
> > don't see the difference between checking for "system_u" and "*system*".
> >
> > Except that "system_u" *is* a valid username, therefore raising the
> > possiblity of conflict between /etc/crontab and the crontab of user
> > system_u.
> 
> If you are using SE Linux then a user name of "system_u" is not going to 
> work, /bin/login etc can't launch shells with system_u as the identity.
> 
> I guess we can have the SE Linux code in crond know that "*system*" means that 
> the identity of "system_u" should be used.
 
 i reworked the patch to add an extra argument to process_crontab.
 the behaviour of the 2nd argument, fname, is left untouched.
 a third argument is added which is set to "system_u" where needed,
 and is identical to the 2nd argument, fname, where needed.
 
 it makes it clear that the two purposes are separate and distinct,
 and i believe it achieves what you intend by the above, which
 would have been to strcmp (fname, "*system*") == 0 inside
 process_crontab and to special-case call get_default_context
 with "system_u" in that instance, yes?

 the extra-argument-patch does the equivalent of that.

 l.

 p.s. this is completely offtopic, but i wish the default world
 language was sanscrit or german or something because when
 describing computer stuff i end up hyphenating english words
 together a lot.  oh well.


--
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: Bug#193644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Luke Kenneth Casson Leighton]

On Wed, May 19, 2004 at 01:11:20PM -0500, Steve Greenland wrote:
> On 19-May-04, 09:02 (CDT), Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote: 
> > On Wed, May 19, 2004 at 09:30:53AM -0400, Stephen Smalley wrote:
> > 
> > > > i take it that this is a more "informative" string
> > > > than "*system*" but it is equally as non-username-ish
> > > > as "*system*" is.
> > > 
> > > It conveys to the SELinux code that we want a security context
> > > appropriate for system cron jobs transparently, as system_u is already
> > > the SELinux user identity for system processes.  And it doesn't hurt
> > > anything, as neither "*system*" nor "system_u" should exist in
> > > /etc/passwd.
> >  
> >   then the maintainer of debian crond needs to be authoritatively
> >   informed of this, as it will help reassure him that no damage is
> >   done by the change.
> 
> I've been informed, I just don't buy it. The only thing that name
> is used for is to generate "names" for the (internal) database, to
> associate it with a particular entry in the list of crontabs, since the
> file names are possibly in conflict with system usernames. The only
> legitimate use for it is to look up entries in that list. It's *NOT* the
> username associated with the crontab. You can't even use it directly,
> because the while the "name" of the /etc/crontab entry is "*system*",
> the names of the /etc/cron.d entries are "*system*/<filename>" (e.g.
> /etc/cron.d/foo maps to "*system*/foo").
> 
> It feels very misleading and confusing to overload it that way, and I
> don't see the difference between checking for "system_u" and "*system*".
> 
> Except that "system_u" *is* a valid username, 

 okay, let's think this through.
 
 it is not a username, it is never expected to be a username...

 ... therefore, i take it that you mean that the letters "system_u"
 _could_ be used as a username, whereas "*" is an invalid character
 which, _if_ used in /etc/passwd, would cause a login error.

 and i take it that _that_ is why you object to its use, yes?


> therefore raising the
> possiblity of conflict between /etc/crontab and the crontab of user
> system_u.

 it's worth double-checking, and russell would be able to confirm:
 on an SELinux system, system_u _can_ never be a valid username...

 ... but that doesn't rule out 

 okay, would "*system_u*" do?

 the thing is that from what i gather, SELinux actually checks things
 via the username that it sees cron jobs create.

 ... *click*.  russell, stephen, isn't that bad??

 surely, things should be done via a SID not a username??

 no ugliness is being buried here, is it? :)


> >  this concatenation will of course make the strcmp against "*system*",
> >  at line 245, FAIL in the case where the 2nd arg to process_crontab
> >  is "*system*someotherinformation"
> > 
> >  this MAY just be a bug in the debian version of cron: i cannot tell
> >  because i do not know enough about it.
> 
> There's no strcmp at line 245 of the debian database.c. What you're
> looking at (probably) is this, around line 327 (beginning of
> process_crontab()):

 yes.

> #ifdef DEBIAN
>     /* If the name begins with *system*, don't worry about password -
>      it's part of the system crontab */
>     if (strncmp(fname, "*system*", 8) && !(pw = getpwnam(uname))) {
> #else
>     if (strcmp(fname, "*system*") && !(pw = getpwnam(uname))) {
> #endif
> 
> 
> And will work fine no matter what "*system*" is (well, so long as it's 8
> characters, and that's trivially fixed with a sizeof()).
 
  around line 215 of cron-3.0pl1/database.c:

		(void) strcpy(fname,"*system*");
		sprintf(tabname,"%s/%s", SYSCRONDIR, dp->d_name);

		/* statbuf is used as working storage by process_crontab() --
		   current contents are irrelevant */
		process_crontab("root", fname, tabname,
				&statbuf, &new_db, old_db);

 yep, you're right: i thought that was sprintf (fname, ... )
 where in fact it's sprintf (tabname).

 so yep, panic over.

 in both vixie-cron and cron3.0pl1 database.c are the same.


> >  is against a vixie-cron where the 2nd argument to process_crontab
> >  is "*system" in BOTH calls to process_crontab, at lines 94 and 136
> >  of database.c.
> > 
> >  i can only point out the discrepancy between the Fedora vixie-cron
> >  and the Debian 3.0 cron (based on vixie-cron): i cannot make an informed
> >  statement about what is right.
> 
> You need to keep the entries for /etc/crontab and /etc/cron.d/ seperate
> or you won't be able to pick up changes in the files. That sounds like
> a Fedora bug, but since I've not looked at that code recently, all I'll
> say is that it's worth looking at.

 no, it's fine: as explained above it's my misreading of the sprintf
 statement in database.c.

 sorry about that.

 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: Bug#193644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Russell Coker]

On Thu, 20 May 2004 06:00, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
>  it's worth double-checking, and russell would be able to confirm:
>  on an SELinux system, system_u _can_ never be a valid username...

Correct.

>  the thing is that from what i gather, SELinux actually checks things
>  via the username that it sees cron jobs create.

It checks that the type of the crontab file is an entry-point for the domain 
used for executing cron jobs.

--
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: Bug#193644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Steve Greenland]

On 19-May-04, 15:00 (CDT), Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote: 
> 
>  ... therefore, i take it that you mean that the letters "system_u"
>  _could_ be used as a username, whereas "*" is an invalid character
>  which, _if_ used in /etc/passwd, would cause a login error.

Yes.

>  and i take it that _that_ is why you object to its use, yes?

No. How many times do I have to say this? It's the WRONG FSCKING FIELD.
The field the SE linux people are so obsessed with changing is NOT
THE USERNAME field. The username field is available. Using it for
controlling the SE context would do the right thing, right? For the
real user crontabs, it would have the real username, even for root. For
the system crontabs, under /etc, it could be system_u. Then calling
SE_get_security_context(username) (or whatever the function/terminology
is) would always be the right thing to do, yes?

(And no, it's not the same as the UID associated with a particular job.
That's yet another field.)

Steve

-- 
Steve Greenland
    The irony is that Bill Gates claims to be making a stable operating
    system and Linus Torvalds claims to be trying to take over the
    world.       -- seen on the net

--
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: Bug#193644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Luke Kenneth Casson Leighton]

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

On Wed, May 19, 2004 at 04:54:09PM -0500, Steve Greenland wrote:
> On 19-May-04, 15:00 (CDT), Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote: 
> > 
> >  ... therefore, i take it that you mean that the letters "system_u"
> >  _could_ be used as a username, whereas "*" is an invalid character
> >  which, _if_ used in /etc/passwd, would cause a login error.
> 
> Yes.
> 
> >  and i take it that _that_ is why you object to its use, yes?
> 
> No. How many times do I have to say this? It's the WRONG FSCKING FIELD.
> The field the SE linux people are so obsessed with changing is NOT
> THE USERNAME field. The username field is available. Using it for
> controlling the SE context would do the right thing, right? 

 no, it wouldn't, because in some cases the context switch must
 come from "system".

 "system" is like... a privilege ABOVE root, and i presume its
 closest equivalent is to the "SYSTEM" SID on the NT
 (actually VAX/VMS) security model.

 i think this can be resolved by adding an extra argument to
 process_crontab.  to put that another way: if an extra
 argument is added which is used solely the selinux context,
 the issue you have, steve, over the change from *system*
 to system_u goes away.

 patch to add extra argument which does not interfere with
 the concept of "*system*" is attached.

 l.


[-- Attachment #2: x --]
[-- Type: text/plain, Size: 4190 bytes --]

--- database.c.old	2004-05-19 09:03:06.000000000 +0000
+++ database.c	2004-05-20 06:04:24.000000000 +0000
@@ -30,6 +30,11 @@
 #include <sys/stat.h>
 #include <sys/file.h>
 
+#ifdef WITH_SELINUX
+#include <selinux/selinux.h>
+#include <selinux/flask.h>
+#include <selinux/av_permissions.h>
+#endif
 
 #define TMAX(a,b) ((a)>(b)?(a):(b))
 
@@ -46,7 +51,11 @@
 
 #endif /* ifndef PATH_MAX */
 
-static	void		process_crontab __P((char *, char *, char *,
+static	void 		process_crontab __P((char *, char *,
+#ifdef WITH_SELINUX
+					     char *,
+#endif
+					     char *,
 					     struct stat *,
 					     cron_db *, cron_db *));
 #ifdef DEBIAN
@@ -168,6 +177,9 @@
 
 	if (syscron_stat.st_mtime) {
 		process_crontab("root", "*system*",
+#ifdef WITH_SELINUX
+				SYSUSERNAME,
+#endif
 				SYSCRONTAB, &syscron_stat,
 				&new_db, old_db);
 	}
@@ -205,7 +217,11 @@
 
 		/* statbuf is used as working storage by process_crontab() --
 		   current contents are irrelevant */
-		process_crontab("root", fname, tabname,
+		process_crontab("root", fname,
+#ifdef WITH_SELINUX
+				SYSUSERNAME,
+#endif
+				tabname,
 				&statbuf, &new_db, old_db);
 
 	}
@@ -236,7 +252,11 @@
 		(void) strcpy(fname, dp->d_name);
 		snprintf(tabname, PATH_MAX+1, CRON_TAB(fname));
 
-		process_crontab(fname, fname, tabname,
+		process_crontab(fname, fname,
+#ifdef WITH_SELINUX
+				fname,
+#endif
+				tabname,
 				&statbuf, &new_db, old_db);
 	}
 	closedir(dir);
@@ -312,9 +332,16 @@
 
 
 static void
-process_crontab(uname, fname, tabname, statbuf, new_db, old_db)
+process_crontab(uname, fname,
+#ifdef WITH_SELINUX
+		se_ctx_name,
+#endif
+		tabname, statbuf, new_db, old_db)
 	char		*uname;
 	char		*fname;
+#ifdef WITH_SELINUX
+	char		*se_ctx_name;
+#endif
 	char		*tabname;
 	struct stat	*statbuf;
 	cron_db		*new_db;
@@ -324,6 +351,13 @@
 	int		crontab_fd = OK - 1;
 	user		*u;
 
+#ifdef WITH_SELINUX
+	security_context_t  file_context=NULL;
+	security_context_t   user_context=NULL;
+	struct av_decision avd;
+	int retval=0, selinux_enabled = (is_selinux_enabled() > 0);
+#endif
+
 #ifdef DEBIAN
 	/* If the name begins with *system*, don't worry about password -
 	 it's part of the system crontab */
@@ -349,6 +383,14 @@
 		goto next_crontab;
             }
 
+#ifdef WITH_SELINUX
+	    if (selinux_enabled) {
+		if (fgetfilecon(crontab_fd, &file_context) < OK) {
+		    log_it(fname, getpid(), "getfilecon FAILED", tabname);
+		    goto next_crontab;
+		}
+	    }
+#endif
             if (fstat(crontab_fd, statbuf) < OK) {
 		log_it(fname, getpid(), "FSTAT FAILED", tabname);
 		goto next_crontab;
@@ -385,6 +427,14 @@
 		goto next_crontab;
             }
 
+#ifdef WITH_SELINUX
+	    if (selinux_enabled) {
+		if (fgetfilecon(crontab_fd, &file_context) < OK) {
+		    log_it(fname, getpid(), "getfilecon FAILED", tabname);
+		    goto next_crontab;
+		}
+	    }
+#endif
             if (fstat(crontab_fd, statbuf) < OK) {
 		log_it(fname, getpid(), "FSTAT FAILED", tabname);
 		goto next_crontab;
@@ -425,6 +475,31 @@
 		free_user(u);
 		log_it(fname, getpid(), "RELOAD", tabname);
 	}
+#ifdef WITH_SELINUX
+	if (selinux_enabled)	{
+		/*
+		 * Since crontab files are not directly executed,
+		 * crond must ensure that the crontab file has
+		 * a context that is appropriate for the context of
+		 * the user cron job.  It performs an entrypoint
+		 * permission check for this purpose.
+		 */
+		if (get_default_context(se_ctx_name, NULL, &user_context)) {
+			log_it(se_ctx_name, getpid(), "NO CONTEXT", tabname);
+			goto next_crontab;
+		}
+		retval = security_compute_av(user_context, file_context,
+			SECCLASS_FILE, FILE__ENTRYPOINT, &avd);
+		freecon(user_context);
+		freecon(file_context);
+		file_context = NULL;
+
+		if (retval || ((FILE__ENTRYPOINT & avd.allowed) != FILE__ENTRYPOINT)) {
+			log_it(fname, getpid(), "ENTRYPOINT FAILED", tabname);
+			goto next_crontab;
+		}
+	}
+#endif
 	u = load_user(crontab_fd, pw, fname);
 	if (u != NULL) {
 		u->mtime = statbuf->st_mtime;
@@ -436,6 +511,12 @@
 		Debug(DLOAD, (" [done]\n"))
 		close(crontab_fd);
 	}
+#ifdef WITH_SELINUX
+	if(file_context) {
+		freecon(file_context);
+		file_context = NULL;
+	}
+#endif
 }
 
 #ifdef DEBIAN

Re: Bug#193644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Stephen Smalley]

On Thu, 2004-05-20 at 02:06, Luke Kenneth Casson Leighton wrote:
>  no, it wouldn't, because in some cases the context switch must
>  come from "system".

No.  We just want "system_u" as the key passed to get_default_context
when dealing with system cron jobs so that it will return a suitable
security context.  So if the username field mentioned by Steve Greenland
can be changed to store system_u for system cron jobs and the normal
username for user-configurable cron jobs, then we can just use it.

>  "system" is like... a privilege ABOVE root, and i presume its
>  closest equivalent is to the "SYSTEM" SID on the NT
>  (actually VAX/VMS) security model.

No.  It is just a way of distinguishing system processes from user
processes.  Calling get_default_context on system_u from crond will
return an appropriate context for system cron jobs (because
get_default_context obtains a context for the specified SELinux user
that is reachable from the current context).

>  i think this can be resolved by adding an extra argument to
>  process_crontab.  to put that another way: if an extra
>  argument is added which is used solely the selinux context,
>  the issue you have, steve, over the change from *system*
>  to system_u goes away.

I don't think that this is necessary; it sounds like we can use the
username field, assuming that it can be system_u for system cron jobs
(or something else that is easily recognizable and can be mapped to
system_u by the SELinux code).

-- 
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: Bug#193644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Luke Kenneth Casson Leighton]

On Thu, May 20, 2004 at 08:06:36AM -0400, Stephen Smalley wrote:

> >  "system" is like... a privilege ABOVE root, and i presume its
> >  closest equivalent is to the "SYSTEM" SID on the NT
> >  (actually VAX/VMS) security model.
> 
> No.  It is just a way of distinguishing system processes from user
> processes.  

 oh, okay :)

 i stand corrected.

> >  i think this can be resolved by adding an extra argument to
> >  process_crontab.  to put that another way: if an extra
> >  argument is added which is used solely the selinux context,
> >  the issue you have, steve, over the change from *system*
> >  to system_u goes away.
> 
> I don't think that this is necessary; it sounds like we can use the
> username field, assuming that it can be system_u for system cron jobs
> (or something else that is easily recognizable and can be mapped to
> system_u by the SELinux code).

 then that leaves the other approach, the one suggested by russell:
 to do a strcmp(fname, "*system*") == 0 in process_crontab, and
 in that specific case to call get_default_context("system_u", ...)

 i don't think steve is going to allow any changes upstream to crond
 because the letters "system_u" _could_ be a valid username used
 by a NON selinux enabled system in /etc/passwd or other security
 system.

 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: Bug#193644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Stephen Smalley]

On Wed, 2004-05-19 at 17:54, Steve Greenland wrote:
> No. How many times do I have to say this? It's the WRONG FSCKING FIELD.
> The field the SE linux people are so obsessed with changing is NOT
> THE USERNAME field. The username field is available. Using it for
> controlling the SE context would do the right thing, right? For the
> real user crontabs, it would have the real username, even for root. For
> the system crontabs, under /etc, it could be system_u. Then calling
> SE_get_security_context(username) (or whatever the function/terminology
> is) would always be the right thing to do, yes?

Yes, if we can get the field to be system_u for system crontabs (at
least when SELinux is enabled), then that would likely be fine. 
get_default_context will then get the proper context for system cron
jobs.

-- 
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: Bug#193644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Luke Kenneth Casson Leighton]

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

On Thu, May 20, 2004 at 07:57:42AM -0400, Stephen Smalley wrote:
> On Wed, 2004-05-19 at 17:54, Steve Greenland wrote:
> > No. How many times do I have to say this? It's the WRONG FSCKING FIELD.
> > The field the SE linux people are so obsessed with changing is NOT
> > THE USERNAME field. The username field is available. Using it for
> > controlling the SE context would do the right thing, right? For the
> > real user crontabs, it would have the real username, even for root. For
> > the system crontabs, under /etc, it could be system_u. Then calling
> > SE_get_security_context(username) (or whatever the function/terminology
> > is) would always be the right thing to do, yes?
> 
> Yes, if we can get the field to be system_u for system crontabs (at
> least when SELinux is enabled), then that would likely be fine. 
> get_default_context will then get the proper context for system cron
> jobs.
 
 okay, what steve is saying is slowly sinking in.

 okay.  in process_crontab, line 360 or thereabouts, comment is
 "if name begins '*system*', don't worry about password".

 therefore, whatever you specify under such circumstances (fname
 == '*system*'), the uname argument is completely irrelevant.
 it could, in fact, be NULL.

 therefore, under such circumstances, whatever is specified in
 uname there can be no objection about.

 therefore, it is perfectly reasonable to do this, at both lines
 179 and 220 or thereabouts:

 process_crontab ("system_u", "*system*", ...)

 now, it so happens that at line 250 or thereabouts, the
 first and 2nd arg are identical (fname).

 conclusion:

 by doing process_crontab ("system_u", "*system*", ...) wherever
 "*system*" is used, and by doing get_default_context(uname, ...)
 inside process_crontab, the correct semantics are maintained.

 so in a roundabout way we conclude what appears to be very
 obvious, namely that instead of selecting "root" as the default
 context, we select "system_u" [in the same circumstances where
 cron "fudges" things by creating something non-user-ish called
 "*system*" which non-selinux-unix doesn't support].

 patch attached.... 

 l.


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

--- database.c.old	2004-05-19 09:03:06.000000000 +0000
+++ database.c	2004-05-20 14:15:55.000000000 +0000
@@ -30,6 +30,11 @@
 #include <sys/stat.h>
 #include <sys/file.h>
 
+#ifdef WITH_SELINUX
+#include <selinux/selinux.h>
+#include <selinux/flask.h>
+#include <selinux/av_permissions.h>
+#endif
 
 #define TMAX(a,b) ((a)>(b)?(a):(b))
 
@@ -167,7 +172,7 @@
 	new_db.head = new_db.tail = NULL;
 
 	if (syscron_stat.st_mtime) {
-		process_crontab("root", "*system*",
+		process_crontab(SYSUSERNAME, "*system*",
 				SYSCRONTAB, &syscron_stat,
 				&new_db, old_db);
 	}
@@ -205,7 +210,7 @@
 
 		/* statbuf is used as working storage by process_crontab() --
 		   current contents are irrelevant */
-		process_crontab("root", fname, tabname,
+		process_crontab(SYSUSERNAME, fname, tabname,
 				&statbuf, &new_db, old_db);
 
 	}
@@ -324,6 +329,13 @@
 	int		crontab_fd = OK - 1;
 	user		*u;
 
+#ifdef WITH_SELINUX
+	security_context_t  file_context=NULL;
+	security_context_t   user_context=NULL;
+	struct av_decision avd;
+	int retval=0, selinux_enabled = (is_selinux_enabled() > 0);
+#endif
+
 #ifdef DEBIAN
 	/* If the name begins with *system*, don't worry about password -
 	 it's part of the system crontab */
@@ -349,6 +361,14 @@
 		goto next_crontab;
             }
 
+#ifdef WITH_SELINUX
+	    if (selinux_enabled) {
+		if (fgetfilecon(crontab_fd, &file_context) < OK) {
+		    log_it(fname, getpid(), "getfilecon FAILED", tabname);
+		    goto next_crontab;
+		}
+	    }
+#endif
             if (fstat(crontab_fd, statbuf) < OK) {
 		log_it(fname, getpid(), "FSTAT FAILED", tabname);
 		goto next_crontab;
@@ -385,6 +405,14 @@
 		goto next_crontab;
             }
 
+#ifdef WITH_SELINUX
+	    if (selinux_enabled) {
+		if (fgetfilecon(crontab_fd, &file_context) < OK) {
+		    log_it(fname, getpid(), "getfilecon FAILED", tabname);
+		    goto next_crontab;
+		}
+	    }
+#endif
             if (fstat(crontab_fd, statbuf) < OK) {
 		log_it(fname, getpid(), "FSTAT FAILED", tabname);
 		goto next_crontab;
@@ -425,6 +453,31 @@
 		free_user(u);
 		log_it(fname, getpid(), "RELOAD", tabname);
 	}
+#ifdef WITH_SELINUX
+	if (selinux_enabled)	{
+		/*
+		 * Since crontab files are not directly executed,
+		 * crond must ensure that the crontab file has
+		 * a context that is appropriate for the context of
+		 * the user cron job.  It performs an entrypoint
+		 * permission check for this purpose.
+		 */
+		if (get_default_context(uname, NULL, &user_context)) {
+			log_it(uname, getpid(), "NO CONTEXT", tabname);
+			goto next_crontab;
+		}
+		retval = security_compute_av(user_context, file_context,
+			SECCLASS_FILE, FILE__ENTRYPOINT, &avd);
+		freecon(user_context);
+		freecon(file_context);
+		file_context = NULL;
+
+		if (retval || ((FILE__ENTRYPOINT & avd.allowed) != FILE__ENTRYPOINT)) {
+			log_it(fname, getpid(), "ENTRYPOINT FAILED", tabname);
+			goto next_crontab;
+		}
+	}
+#endif
 	u = load_user(crontab_fd, pw, fname);
 	if (u != NULL) {
 		u->mtime = statbuf->st_mtime;
@@ -436,6 +489,12 @@
 		Debug(DLOAD, (" [done]\n"))
 		close(crontab_fd);
 	}
+#ifdef WITH_SELINUX
+	if(file_context) {
+		freecon(file_context);
+		file_context = NULL;
+	}
+#endif
 }
 
 #ifdef DEBIAN
--- cron.h.old	2004-05-19 09:03:48.000000000 +0000
+++ cron.h	2004-05-20 14:17:39.000000000 +0000
@@ -40,6 +40,12 @@
 #include "config.h"
 #include "externs.h"
 
+#ifdef WITH_SELINUX 
+#define SYSUSERNAME "system_u"
+#else
+#define SYSUSERNAME "root"
+#endif
+
 	/* these are really immutable, and are
 	 *   defined for symbolic convenience only
 	 * TRUE, FALSE, and ERR must be distinct

Re: Bug#193644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Steve Greenland]

On 20-May-04, 09:22 (CDT), Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote: 
>  therefore, whatever you specify under such circumstances (fname
>  == '*system*'), the uname argument is completely irrelevant.
>  it could, in fact, be NULL.
> 
>  therefore, under such circumstances, whatever is specified in
>  uname there can be no objection about.
> 
>  therefore, it is perfectly reasonable to do this, at both lines
>  179 and 220 or thereabouts:
> 
>  process_crontab ("system_u", "*system*", ...)

Bingo. 

>  now, it so happens that at line 250 or thereabouts, the
>  first and 2nd arg are identical (fname).
> 
>  conclusion:
> 
>  by doing process_crontab ("system_u", "*system*", ...) wherever
>  "*system*" is used, and by doing get_default_context(uname, ...)
>  inside process_crontab, the correct semantics are maintained.

Yes.

Thanks for following this through. I'll look at the patch this weekend.

Hmmm. One Debian specific problem. libselinux1 is priority "optional",
while cron is "important". I guess I need to talk to Colin Walters.

Steve


-- 
Steve Greenland
    The irony is that Bill Gates claims to be making a stable operating
    system and Linus Torvalds claims to be trying to take over the
    world.       -- seen on the net

--
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: Bug#193644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Russell Coker]

On Fri, 21 May 2004 01:48, Steve Greenland <steveg@moregruel.net> wrote:
> Hmmm. One Debian specific problem. libselinux1 is priority "optional",
> while cron is "important". I guess I need to talk to Colin Walters.

No problem.  I have already uploaded a new version with priority "required".

Colin doesn't seem to be doing any SE Linux work at the moment, so he's passed 
his SE Linux packages to me.

-- 
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: Bug#193644: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193644 (cron upstream patch)

[Luke Kenneth Casson Leighton]

On Thu, May 20, 2004 at 10:48:49AM -0500, Steve Greenland wrote:

> >  by doing process_crontab ("system_u", "*system*", ...) wherever
> >  "*system*" is used, and by doing get_default_context(uname, ...)
> >  inside process_crontab, the correct semantics are maintained.
> 
> Yes.
> 
> Thanks for following this through. I'll look at the patch this weekend.
> 
> Hmmm. One Debian specific problem. libselinux1 is priority "optional",
> while cron is "important". I guess I need to talk to Colin Walters.
 
 ultimately it needs to be priority "required" and essential "yes"
 because programs in coreutils (e.g. ls) need libselinux1.

 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.