start of patch to dpkg's start-stop-daemon

start of patch to dpkg's start-stop-daemon

[Luke Kenneth Casson Leighton]

hi,

steve, russell, would you mind taking a quick look at this?

it's a patch to dpkg 1.10.21's utils/start-stop-daemon.c
which causes a context switch just before
the setuid/setgid calls.

now, whether this is required behaviour or not, i cannot say.

what i do believe is that if start-stop-daemon is used with -u UID
instead of username, and there _is_ no username associated with
that UID, then the resultant failure will, on an SE/Linux system,
be a Good Thing.

hey, maybe it isn't good, maybe people expect a fallback to
user_u context, i don't know.

maybe there should be an extra option to start-stop-daemon
to specify the context separately: again, i don't know.


i put the context execution switch in after the opening of
/dev/ttyX and after the chroot, but before the setgid/setuid/setgroups.

and without doing anything to the file handle of the /dev/ttyX.

oh, and also after, and without doing anything to, the opening
of the /var/run/daemon_name.pid file.

... is that right?  should those file handles be in and remain
in the initrd_t context?

should the user-context-switch be done at all??

sincerely,

l.

--- start-stop-daemon.c.old	2004-05-20 08:32:31.000000000 +0000
+++ start-stop-daemon.c	2004-05-20 08:32:34.000000000 +0000
@@ -93,6 +93,11 @@
   #include <hurd/ihash.h>
 #endif
 
+#ifdef WITH_SELINUX
+#include <selinux/get_context_list.h>
+#include <selinux/selinux.h>
+#endif
+
 static int testmode = 0;
 static int quietmode = 0;
 static int exitnodo = 1;
@@ -1245,6 +1250,37 @@
 	if (chdir(changedir) < 0)
 		fatal("Unable to chdir() to %s", changedir);
 	if (changeuser != NULL) {
+
+    /*
+     * for Security Enhanced Linux,
+     * set the default security context for this user.
+     */
+#ifdef WITH_SELINUX
+   if (is_selinux_enabled() > 0)
+   {
+        security_context_t scontext;
+
+		/* changeuser could be specified as a uid, so we need to look
+		 * up the username.  this _could_ be expected to fail if someone
+		 * is deliberately using a uid with no username associated with
+		 * it, in which case, tough: this is SE/Linux not Unix.
+		 */
+		struct passwd *pw = getpwnam(runas_uid);
+		if (pw == NULL || pw->pw_name == NULL)
+			fatal("uid `%d' not found username\n", runas_uid);
+
+        if (get_default_context(pw->pw_name,NULL,&scontext))
+		{
+             fatal("Failed to get default security context for %s.", curuser);
+		}
+        Debug("setting security context to %s", scontext);
+        if (setexeccon(scontext)) {
+             freecon(scontext);
+             fatal("Failed to set exec security context %s for %s.", scontext, curuser);
+        }
+        freecon(scontext);
+   }
+#endif
  		if (setgid(runas_gid))
  			fatal("Unable to set gid to %d", runas_gid);
 		if (initgroups(changeuser, runas_gid))
-- 
-- 
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 />


--
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: start of patch to dpkg's start-stop-daemon

[Russell Coker]

On Thu, 20 May 2004 18:43, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> it's a patch to dpkg 1.10.21's utils/start-stop-daemon.c
> which causes a context switch just before
> the setuid/setgid calls.

What is the benefit in that?

start-stop-daemon is designed to be run from a /etc/init.d/* script.  That 
script will run as system_u:system_r:initrc_t and there will be a 
domain_auto_trans() rule to cause the daemon to be started as 
system_u:system_r:whatever_t.

start-stop-daemon is also run from cron jobs, in that case it will run as 
system_u:system_r:system_crond_t (in which case the program it runs will have 
any appropriate domain transition automatically), or it will run as the cron 
domain for the daemon (IE the script that calls start-stop-daemon has a 
domain transition *) and again it doesn't need to do anything special.

*)  domain_auto_trans() rules that allow script execution to have more privs 
than the calling code is bad.  But having the script execute with less privs 
is OK (not great but OK).

-- 
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: start of patch to dpkg's start-stop-daemon

[Luke Kenneth Casson Leighton]

On Fri, May 21, 2004 at 01:32:17AM +1000, Russell Coker wrote:
> On Thu, 20 May 2004 18:43, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > it's a patch to dpkg 1.10.21's utils/start-stop-daemon.c
> > which causes a context switch just before
> > the setuid/setgid calls.
> 
> What is the benefit in that?
 
 uhm...

 mmm...
 
 it's easier than breaking pre-existing /etc/init.d/* scripts where 
 people expect the -u option to act as it should?

 in other words, the benefit in patching start-stop-daemon is to
 provide legacy transition support.

 i _really_ don't want the -u option on my custom /etc/init.d/custom
 script to suddenly start running the daemon as root.

 as an inexperienced SE/Linux user i might not _know_ that i have to
 write a domain_auto_trans() rule in the /etc/selinux policy.

 therefore all of a sudden, by upgrading to SE/Linux i suddenly have
 my -u option effectively ignored.

 under which circumstances, what you are saying is that
 because the script will run as system_u:system_r:initrc_t,
 and because that context will not have (shouldn't have!)
 permission to do anything outrageous, my startup script will
 break.

 well, that's better than nothing (an "i can't... " is a LOT
 better than "i didn't know it could...") , but it's still a pain.

 
 so, the benefit is: not so much pain.

 is that a good enough reason?

 sincerely,

 l.


> start-stop-daemon is designed to be run from a /etc/init.d/* script.  That 
> script will run as system_u:system_r:initrc_t and there will be a 
> domain_auto_trans() rule to cause the daemon to be started as 
> system_u:system_r:whatever_t.
> 
> start-stop-daemon is also run from cron jobs, in that case it will run as 
> system_u:system_r:system_crond_t (in which case the program it runs will have 
> any appropriate domain transition automatically), or it will run as the cron 
> domain for the daemon (IE the script that calls start-stop-daemon has a 
> domain transition *) and again it doesn't need to do anything special.
> 
> *)  domain_auto_trans() rules that allow script execution to have more privs 
> than the calling code is bad.  But having the script execute with less privs 
> is OK (not great but OK).
> 
> -- 
> 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

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


--
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: start of patch to dpkg's start-stop-daemon

[Russell Coker]

On Fri, 21 May 2004 02:23, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > > it's a patch to dpkg 1.10.21's utils/start-stop-daemon.c
> > > which causes a context switch just before
> > > the setuid/setgid calls.
> >
> > What is the benefit in that?
>
>  it's easier than breaking pre-existing /etc/init.d/* scripts where
>  people expect the -u option to act as it should?

How is it broken?  initrc_t has setuid and setgid capabilities so SE Linux 
does not stop the regular function of start-stop-daemon.

In fact it's good for start-stop-daemon to be used to run a daemon as UID != 
0, that means that the daemon domain does not need setuid capability.

>  in other words, the benefit in patching start-stop-daemon is to
>  provide legacy transition support.

My systems have been working fine with a non-patched start-stop-daemon for two 
years.  When I first started working on SE Linux I had a similar idea to 
avoid the use of run_init, that turned out to be a bad idea and I've been 
using the regular start-stop-daemon since then.

>  i _really_ don't want the -u option on my custom /etc/init.d/custom
>  script to suddenly start running the daemon as root.

Why not?

If root is the appropriate UID for Unix permissions to allow all required 
operations, then this is OK as SE Linux can still prevent it from doing 
anything bad.

>  as an inexperienced SE/Linux user i might not _know_ that i have to
>  write a domain_auto_trans() rule in the /etc/selinux policy.
>
>  therefore all of a sudden, by upgrading to SE/Linux i suddenly have
>  my -u option effectively ignored.

No, if you install a daemon which has no policy and you don't write any then 
the daemon will run as initrc_t.  This may allow the daemon to work or may 
prevent it from operating depending on what the daemon does.

>  under which circumstances, what you are saying is that
>  because the script will run as system_u:system_r:initrc_t,
>  and because that context will not have (shouldn't have!)
>  permission to do anything outrageous, my startup script will
>  break.

initrc_t has a lot of access to the system.  It's designed for startup scripts 
and breaks very few of them.

-- 
http://apac.redhat.com/disclaimer
See above URL for disclaimer.

--
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: start of patch to dpkg's start-stop-daemon

[Luke Kenneth Casson Leighton]

On Fri, May 21, 2004 at 03:33:37AM +1000, Russell Coker wrote:
> On Fri, 21 May 2004 02:23, Luke Kenneth Casson Leighton <lkcl@lkcl.net> wrote:
> > > > it's a patch to dpkg 1.10.21's utils/start-stop-daemon.c
> > > > which causes a context switch just before
> > > > the setuid/setgid calls.
> > >
> > > What is the benefit in that?
> >
> >  it's easier than breaking pre-existing /etc/init.d/* scripts where
> >  people expect the -u option to act as it should?
> 
> How is it broken?  initrc_t has setuid and setgid capabilities so SE Linux 
> does not stop the regular function of start-stop-daemon.
 
 ..o*??  ah, cool, that's very smart, i wasn't expecting that.

 i learn something new every day :)

> >  in other words, the benefit in patching start-stop-daemon is to
> >  provide legacy transition support.
> 
> My systems have been working fine with a non-patched start-stop-daemon for two 
> years.  When I first started working on SE Linux I had a similar idea to 
> avoid the use of run_init, that turned out to be a bad idea and I've been 
> using the regular start-stop-daemon since then.
> 
> >  i _really_ don't want the -u option on my custom /etc/init.d/custom
> >  script to suddenly start running the daemon as root.
> 
> Why not?
 
 ignore all the rest of my comments: they were based on the assumption
 that initrc_t would not allow setuid or setgid.

 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.