init patch for loading policy

init patch for loading policy

[Russell Coker]

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

I've attached a patch for /sbin/init to load the policy and set enforcing 
mode.  Here's a quick summary of the algorithm:

0)  Only reach our code if the PIPE code for detecting "telinit u" does not 
get a hit.  Therefore we know that we are executed on either a SEGV of the 
original init or the initial boot.
1)  Check for readability of /selinux/enforce, if it's readable then we have 
just exec'd ourselves so go to FINISH.
2)  Mount /selinux, if success then go to 5.
3)  Mount /proc, if error then go to FINISH (*).
4)  Check /proc/filesystems for selinuxfs entry, if it's not there then we 
aren't running an SE Linux kernel so go to FINISH.  If it's there then we 
have a serious error condition so go to ERR (I forgot to close a file handle, 
not that it matters much - I'll fix it later).
5)  load_policy - if error then go to ERR.
6)  Set enforcing mode, if error then go to ERR.
7)  Exec itself to get init_t, if can't exec then fall through to ERR.
ERR) Sleep for 60 seconds after displaying message then halt machine (*).
FINISH) Continue with regular init startup.

The (*)'s indicate issues that are open for discussion.  The exact actions may 
be contentious.

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

[-- Attachment #2: init.diff --]
[-- Type: text/x-diff, Size: 1603 bytes --]

diff -ru orig/sysvinit-2.85/src/init.c sysvinit-2.85/src/init.c
--- orig/sysvinit-2.85/src/init.c	2003-10-19 20:25:32.000000000 +1000
+++ sysvinit-2.85/src/init.c	2003-10-20 01:00:47.000000000 +1000
@@ -2508,6 +2508,7 @@
 	char			*p;
 	int			f;
 	int			isinit;
+	FILE			*fp;
 
 	/* Get my own name */
 	if ((p = strrchr(argv[0], '/')) != NULL)
@@ -2551,6 +2552,55 @@
 		init_main();
 	}
 
+#ifdef WITH_SELINUX
+	if(!access("/selinux/enforce", R_OK))
+		goto finished;
+
+	if(system("mount -n none /selinux -t selinuxfs"))
+	{
+		char buf[64];
+		if(system("mount -n none /proc -t proc"))
+		{
+			fprintf(stderr, "Can't mount /selinux or /proc\n");
+			goto finished;
+		}
+		fp = fopen("/proc/filesystems", "r");
+		if(!fp)
+		{
+			fprintf(stderr, "Can't open /proc/filesystems");
+			goto err;
+		}
+		while(fgets(buf, sizeof(buf), fp))
+		{
+			if(strstr(buf, "selinuxfs"))
+			{
+				fprintf(stderr, "SE Linux is enabled but can't mount /selinux");
+				goto err;
+			}
+		}
+		fclose(fp); /* non-SE kernel */
+		goto finished;
+	}
+	if(system("/usr/sbin/load_policy /etc/security/selinux/policy.15"))
+	{
+		fprintf(stderr, "Can't load policy");
+		goto err;
+	}
+	fp = fopen("/selinux/enforce", "w");
+	if(!fp || 1 != fwrite("1", 1, 1, fp))
+	{
+		fprintf(stderr, "Can't set enforcing mode.\n");
+		goto err;
+	}
+	fclose(fp);
+	execv("/sbin/init", argv);
+	fprintf(stderr, "Can't re-exec init to get right context.\n");
+err:
+	sleep(60);
+	init_reboot(BMAGIC_HALT);
+finished:
+#endif
+
   	/* Check command line arguments */
 	maxproclen = strlen(argv[0]) + 1;
   	for(f = 1; f < argc; f++) {

Re: init patch for loading policy

[Carsten Grohmann]

Am Sonntag, 19. Oktober 2003 17:48 schrieb Russell Coker:
> I've attached a patch for /sbin/init to load the policy and set
> enforcing mode.  Here's a quick summary of the algorithm:

That's great! Last Friday I had a lot of problems with the initrd 
(and my patched mkinitrd for SuSE) and I hope we don't need it in 
the future.

Could we parse the kernel command line to check the SELinux mode. 
I'm not sure if a general start in the enforcing mode a good idea.

Carsten




--
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: init patch for loading policy

[Stephen Smalley]

On Sun, 2003-10-19 at 11:48, Russell Coker wrote:
> I've attached a patch for /sbin/init to load the policy and set enforcing 
> mode.  

Would it be cleaner to just do this via a script run from
/etc/rc.d/rc.sysinit?  It seems a bit ugly to patch this directly into
/sbin/init.  The script could perform a 'telinit u' after loading the
policy to trigger the domain transition for the init process, and would
simply return immediately upon the second invocation when it detected
that selinuxfs was already mounted.

> 3)  Mount /proc, if error then go to FINISH (*).
> 4)  Check /proc/filesystems for selinuxfs entry, if it's not there then we 
> aren't running an SE Linux kernel so go to FINISH.  If it's there then we 
> have a serious error condition so go to ERR (I forgot to close a file handle, 
> not that it matters much - I'll fix it later).

This should be indicated by the return code / error message when you try
to mount selinuxfs.

> 6)  Set enforcing mode, if error then go to ERR.

This will always fail on a kernel that was built with
CONFIG_SECURITY_SELINUX_DEVELOP=n, as /selinux/enforce will not define a
write operation in that case.  Also, it would require booting with an
alternate init program in order to boot permissive.  There doesn't seem
to be any reason to do this, as you can specify enforcing=1 on the
kernel command line or enable it via rc.sysinit if desired.

-- 
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: init patch for loading policy

[Daniel J Walsh]

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

Stephen Smalley wrote:

>On Sun, 2003-10-19 at 11:48, Russell Coker wrote:
>  
>
>>I've attached a patch for /sbin/init to load the policy and set enforcing 
>>mode.  
>>    
>>
>
>Would it be cleaner to just do this via a script run from
>/etc/rc.d/rc.sysinit?  It seems a bit ugly to patch this directly into
>/sbin/init.  The script could perform a 'telinit u' after loading the
>policy to trigger the domain transition for the init process, and would
>simply return immediately upon the second invocation when it detected
>that selinuxfs was already mounted.
>
>  
>
I don-t believe that would not re-start the rc.sysinit process in the 
correct context.

>>3)  Mount /proc, if error then go to FINISH (*).
>>4)  Check /proc/filesystems for selinuxfs entry, if it's not there then we 
>>aren't running an SE Linux kernel so go to FINISH.  If it's there then we 
>>have a serious error condition so go to ERR (I forgot to close a file handle, 
>>not that it matters much - I'll fix it later).
>>    
>>
>
>This should be indicated by the return code / error message when you try
>to mount selinuxfs.
>
>  
>
>>6)  Set enforcing mode, if error then go to ERR.
>>    
>>
>
>This will always fail on a kernel that was built with
>CONFIG_SECURITY_SELINUX_DEVELOP=n, as /selinux/enforce will not define a
>write operation in that case.  Also, it would require booting with an
>alternate init program in order to boot permissive.  There doesn't seem
>to be any reason to do this, as you can specify enforcing=1 on the
>kernel command line or enable it via rc.sysinit if desired.
>
>  
>

[-- Attachment #2: Type: text/html, Size: 2301 bytes --]

Re: init patch for loading policy

[Stephen Smalley]

On Mon, 2003-10-20 at 16:10, Daniel J Walsh wrote:
> I don-t believe that would not re-start the rc.sysinit process in the
> correct context.

What if we were to replace the sysinit entry in /etc/inittab with one
that ran a new script that mounts selinuxfs, loads the policy, and runs
'telinit u' to restart init in the correct domain, and add a bootwait
entry to /etc/inittab that runs the ordinary rc.sysinit script?  In that
case, init should run the new script that loads the policy, re-exec
itself into the right domain due to the telinit -u command, and then
proceed to run the rc.sysinit script.  Or this might even work with two
sysinit entries, as long as they are executed in the right order.

-- 
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: init patch for loading policy

[Daniel J Walsh]

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

Stephen Smalley wrote:

>On Mon, 2003-10-20 at 16:10, Daniel J Walsh wrote:
>  
>
>>I don-t believe that would not re-start the rc.sysinit process in the
>>correct context.
>>    
>>
>
>What if we were to replace the sysinit entry in /etc/inittab with one
>that ran a new script that mounts selinuxfs, loads the policy, and runs
>'telinit u' to restart init in the correct domain, and add a bootwait
>entry to /etc/inittab that runs the ordinary rc.sysinit script?  In that
>case, init should run the new script that loads the policy, re-exec
>itself into the right domain due to the telinit -u command, and then
>proceed to run the rc.sysinit script.  Or this might even work with two
>sysinit entries, as long as they are executed in the right order.
>
>  
>

I don't believe there is anyway to get init to re-run the initscripts 
which means that no scripts will get started from the 'correct ' init,  
unless you change run-level. 

Dan

[-- Attachment #2: Type: text/html, Size: 1398 bytes --]

Re: init patch for loading policy

[Stephen Smalley]

On Mon, 2003-10-20 at 16:56, Daniel J Walsh wrote:
> I don't believe there is anyway to get init to re-run the initscripts
> which means that no scripts will get started from the 'correct '
> init,  unless you change run-level.  

I'd suggest trying it before giving up on this path, as it is obviously
cleaner than patching /sbin/init.

-- 
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: init patch for loading policy

[Russell Coker]

On Tue, 21 Oct 2003 04:02, Stephen Smalley wrote:
> > I've attached a patch for /sbin/init to load the policy and set enforcing
> > mode.
>
> Would it be cleaner to just do this via a script run from
> /etc/rc.d/rc.sysinit?  It seems a bit ugly to patch this directly into
> /sbin/init.  The script could perform a 'telinit u' after loading the
> policy to trigger the domain transition for the init process, and would
> simply return immediately upon the second invocation when it detected
> that selinuxfs was already mounted.

Firstly we would need to test that init will actually respond correctly to 
"telinit u" while it's in that stage.  This is something I am concerned 
about, particularly regarding race conditions regarding the completion of 
rc.sysinit (although I guess it's unlikely that rc.sysinit will complete 
before init restarts).

Then there's the issue that rc.sysinit has to get the correct context, so we 
probably need domain_auto_trans(kernel_t, initrc_exec_t, initrc_t).

> > 4)  Check /proc/filesystems for selinuxfs entry, if it's not there then
> > we aren't running an SE Linux kernel so go to FINISH.  If it's there then
> > we have a serious error condition so go to ERR (I forgot to close a file
> > handle, not that it matters much - I'll fix it later).
>
> This should be indicated by the return code / error message when you try
> to mount selinuxfs.
>
> > 6)  Set enforcing mode, if error then go to ERR.
>
> This will always fail on a kernel that was built with
> CONFIG_SECURITY_SELINUX_DEVELOP=n, as /selinux/enforce will not define a
> write operation in that case.  Also, it would require booting with an
> alternate init program in order to boot permissive.  There doesn't seem
> to be any reason to do this, as you can specify enforcing=1 on the
> kernel command line or enable it via rc.sysinit if desired.

OK.  I'll write a new version of the patch to address these issues.

-- 
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: init patch for loading policy

[Stephen Smalley]

On Mon, 2003-10-20 at 20:52, Russell Coker wrote:
> Firstly we would need to test that init will actually respond correctly to 
> "telinit u" while it's in that stage.  This is something I am concerned 
> about, particularly regarding race conditions regarding the completion of 
> rc.sysinit (although I guess it's unlikely that rc.sysinit will complete 
> before init restarts).

Note that I subsequently suggested (in a reply to Dan on the list) using
a separate sysinit entry with its own script for performing the initial
policy load and restarting init, followed by the ordinary sysinit entry
(or alternately, a bootwait entry if you can't ensure ordering among
multiple sysinit entries) that executes rc.sysinit.

This might not work, but I thought it would be worth testing, as it
avoids any patching or redirection of /sbin/init, and only involves an
alteration to /etc/inittab and an additional init script.  I agree that
even if it did work experimentally, you would want to examine the init
code to verify that it is safe in general.

> Then there's the issue that rc.sysinit has to get the correct context, so we 
> probably need domain_auto_trans(kernel_t, initrc_exec_t, initrc_t).

Not necessary with the above approach, as the first sysinit entry should
run in kernel_t and the second entry will automatically be placed into
initrc_t because init will have switched into its domain.

> OK.  I'll write a new version of the patch to address these issues.

Again, I don't think you want to directly patch this into /sbin/init.  
You are executing shell commands, mounting filesystems, etc; do it in a
shell script either by redirecting /sbin/init or by patching /sbin/init
to run an initialization script prior to doing anything else.  Think
about maintenance and also about getting this change upstream; there is
a significant difference between a patch that just adds code to execute
a separate script that can be customized vs. a patch that hardcodes this
particular set of logic into init.

-- 
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: init patch for loading policy

[Russell Coker]

On Tue, 21 Oct 2003 22:29, Stephen Smalley wrote:
> On Mon, 2003-10-20 at 20:52, Russell Coker wrote:
> > Firstly we would need to test that init will actually respond correctly
> > to "telinit u" while it's in that stage.  This is something I am
> > concerned about, particularly regarding race conditions regarding the
> > completion of rc.sysinit (although I guess it's unlikely that rc.sysinit
> > will complete before init restarts).
>
> Note that I subsequently suggested (in a reply to Dan on the list) using
> a separate sysinit entry with its own script for performing the initial
> policy load and restarting init, followed by the ordinary sysinit entry
> (or alternately, a bootwait entry if you can't ensure ordering among
> multiple sysinit entries) that executes rc.sysinit.

OK, I've done some tests of this.  "telinit u" does not work before the 
rc.sysinit script is complete (no read-write file system for communication).

This means that init will be in kernel_t for the duration of rc.sysinit which 
means that some domains will need to send sigchld to kernel_t (syslogd_t is 
one example, but there are others, and some of them are conditional upon the 
system configuration - I may have to allow all daemon domains to send sigchld 
to kernel_t).

init needs to create /dev/initctl as kernel_t, and it locks the utmp file and 
opens wtmp for writing before it can be signalled to re-exec itself.

#!/bin/bash
mount -n /selinux
/usr/sbin/load_policy /etc/security/selinux/policy.15
exec /etc/rc.d/rc.sysinit

I put the above in /etc/rc.d/rc.sysinit.selinux and made init run that instead 
of /etc/rc.d/rc.sysinit.selinux.  When rc.sysinit is exec'd it will be in 
initrc_t as I have put in the following policy:
domain_auto_trans(kernel_t, initrc_exec_t, initrc_t)

One final problem I have not solved yet is messages such as:
avc:  denied  { use } for  pid=391 exe=/usr/sbin/updfstab path=/dev/console 
dev=62:00 ino=160079 scontext=system_u:system_r:updfstab_t 
tcontext=system_u:system_r:kernel_t tclass=fd

I modified rc.sysinit so that when it re-runs itself through /sbin/initlog it 
redirects stdin, stdout, and stderr to /dev/console (thus the three main file 
handles only need to be inherited from initrc_t).  But that doesn't help.  
The results I have so far indicate that this approach has significant 
problems.

Diverting /sbin/init with a shell script works better than this.

-- 
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: init patch for loading policy

[Stephen Smalley]

On Tue, 2003-10-21 at 10:43, Russell Coker wrote: 
> The results I have so far indicate that this approach has significant 
> problems.
> 
> Diverting /sbin/init with a shell script works better than this.

Ok, thanks for looking into it.  So what exactly is the problem with
diverting /sbin/init again?  

-- 
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: init patch for loading policy

[Russell Coker]

On Wed, 22 Oct 2003 00:59, Stephen Smalley wrote:
> On Tue, 2003-10-21 at 10:43, Russell Coker wrote:
> > The results I have so far indicate that this approach has significant
> > problems.
> >
> > Diverting /sbin/init with a shell script works better than this.
>
> Ok, thanks for looking into it.  So what exactly is the problem with
> diverting /sbin/init again?

No insurmountable problem.  I have the following script as /sbin/init, I have 
the real init as /sbin/init.real, and I modified the telinit sym-link 
accordingly.  It seems that init gets re-exec'd for some reason I'm still not 
sure about.  That means that bash gets run in init_t and wants some extra 
access.  But that's not significant.

Diverting /sbin/init may be our best option.

allow init_t devtty_t:chr_file { read write };
allow init_t proc_t:file { read };


#!/bin/sh

if [ ! -d /proc/1 ]; then
  mount -n /proc
fi
grep -q selinuxfs /proc/filesystems || exec /sbin/init.real "$@"
if [ ! -f /selinux/enforce ]; then
  mount -n /selinux
  /usr/sbin/load_policy /etc/security/selinux/policy.15
  if [ -f /selinux/enforce ]; then
    echo 1 > /selinux/enforce
  else
    echo "Can't set enforcing mode"
  fi
fi
exec /sbin/init.real "$@"


-- 
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: init patch for loading policy

[Daniel J Walsh]

Init has logic in it to look at its argv[0] to see if it is init.  If it 
is not it thinks it is telinit.

Dan


--
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: init patch for loading policy

[Bastian Blank]

On Wed, Oct 22, 2003 at 02:00:35AM +1000, Russell Coker wrote:
> #!/bin/sh
> 
if [ $$ = 1 ]; then
if [ ! -e /proc/self ]; then
>   mount -n /proc
> fi
> grep -q selinuxfs /proc/filesystems || exec /sbin/init.real "$@"
> if [ ! -f /selinux/enforce ]; then
hmm? you check for the non-existance first and for existance later
>   mount -n /selinux
>   /usr/sbin/load_policy /etc/security/selinux/policy.15
>   if [ -f /selinux/enforce ]; then
>     echo 1 > /selinux/enforce
>   else
>     echo "Can't set enforcing mode"
>   fi
isn't enforcing mode set according to the compiletime flags?
> fi
fi
> exec /sbin/init.real "$@"

bastian

-- 
Warp 7 -- It's a law we can live with.

--
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: init patch for loading policy

[Daniel J Walsh]

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

Stephen Smalley wrote:

>On Tue, 2003-10-21 at 10:43, Russell Coker wrote: 
>  
>
>>The results I have so far indicate that this approach has significant 
>>problems.
>>
>>Diverting /sbin/init with a shell script works better than this.
>>    
>>
>
>Ok, thanks for looking into it.  So what exactly is the problem with
>diverting /sbin/init again?  
>
>  
>
I still believe that the patch to /sbin/init is simple enough that all 
the rest of this stuff is complicating matters.  It allows too many ways 
for someone to make a modification that breaks security.  I have updated 
the files on people.redhat.com/dwalsh to use the modified init.  I have 
passed this by Bill Nottingham (Red Hat maintainer) and he is ok with it.

Of course if someone comes up with a simpler solution we would look at it.

Dan



[-- Attachment #2: Type: text/html, Size: 1281 bytes --]

Re: init patch for loading policy

[Joubert Berger]

Could you not hard code enough of a policy in the kernel to get init(8)
up and running?  Then let init run a script that loads the complete
policy and then runs /etc/rc.d/rc.sysinit or just have rc.sysinit load
it as it's first step.

--joubert

On Tue, 2003-10-21 at 13:50, Daniel J Walsh wrote:
> Stephen Smalley wrote:
> > On Tue, 2003-10-21 at 10:43, Russell Coker wrote: 
> >   
> > > The results I have so far indicate that this approach has significant 
> > > problems.
> > > 
> > > Diverting /sbin/init with a shell script works better than this.
> > >     
> > Ok, thanks for looking into it.  So what exactly is the problem with
> > diverting /sbin/init again?  
> > 
> >   
> I still believe that the patch to /sbin/init is simple enough that all
> the rest of this stuff is complicating matters.  It allows too many
> ways for someone to make a modification that breaks security.  I have
> updated the files on people.redhat.com/dwalsh to use the modified
> init.  I have passed this by Bill Nottingham (Red Hat maintainer) and
> he is ok with it.
> 
> Of course if someone comes up with a simpler solution we would look at
> it.
> 
> Dan
> 
> 


--
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: init patch for loading policy

[Russell Coker]

On Thu, 23 Oct 2003 08:31, Joubert Berger wrote:
> Could you not hard code enough of a policy in the kernel to get init(8)
> up and running?  Then let init run a script that loads the complete
> policy and then runs /etc/rc.d/rc.sysinit or just have rc.sysinit load
> it as it's first step.

This would demand that the kernel be hard coded for init to run in init_t, for 
it's executable to be init_exec_t, and policy to allow init to execute 
load_policy.

This wouldn't necessarily be a good thing, there have already been discussions 
of SE policies that don't have init_t, such policies would conflict with 
hard-coding of the nature which you suggest.

-- 
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: init patch for loading policy

[Daniel J Walsh]

[-- Attachment #1.1: Type: text/plain, Size: 408 bytes --]

Stephen Smalley wrote:

>On Tue, 2003-10-21 at 10:43, Russell Coker wrote: 
>  
>
>>The results I have so far indicate that this approach has significant 
>>problems.
>>
>>Diverting /sbin/init with a shell script works better than this.
>>    
>>
>
>Ok, thanks for looking into it.  So what exactly is the problem with
>diverting /sbin/init again?  
>  
>

Here is my patch to init to load initial policy.



[-- Attachment #1.2: Type: text/html, Size: 859 bytes --]

[-- Attachment #2: sysvinit-selinux.patch --]
[-- Type: text/plain, Size: 3586 bytes --]

--- sysvinit-2.85/src/init.c.selinux	2003-10-21 11:01:52.000000000 -0400
+++ sysvinit-2.85/src/init.c	2003-10-21 11:18:20.000000000 -0400
@@ -78,6 +78,87 @@
 			sigemptyset(&sa.sa_mask); \
 			sigaction(sig, &sa, NULL); \
 		} while(0)
+#ifdef WITH_SELINUX
+#include <sys/mman.h>
+#include <selinux/selinux.h>
+#include <sys/mount.h>
+
+#define POLICY_FILE "/etc/security/selinux/policy"
+#define DEFAULT_POLICY_VERSION 15
+#define SELINUXMNT "/selinux"
+#define POLICY_VERSION_FILE "/selinux/policyvers"
+#define SELINUX_ENFORCE_FILE "/selinux/enforce"
+static int load_policy(int *enforce) 
+{
+  int fd,ret=-1;
+  struct stat sb;
+  void *map;
+  char policy_file[PATH_MAX];
+  int policy_version=DEFAULT_POLICY_VERSION;
+  FILE *fp;
+
+  log(L_VB, "Loading security policy\n");
+  if (mount("none", SELINUXMNT, "selinuxfs", 0, 0) < 0) {
+    if (errno == ENODEV) {
+      log(L_VB, "SELinux not supported by kernel: %s\n",SELINUXMNT,strerror(errno));
+    } 
+    else {
+      log(L_VB, "Failed to mount %s: %s\n",SELINUXMNT,strerror(errno));
+      exit(1);
+    }
+    return ret; /* Never gets here */
+  }
+
+  /* Check policy version file.  For now this will default to 15.  When all 
+     kernel supports POLICY_VERSION_FILE, this should become an error */
+  fp = fopen(POLICY_VERSION_FILE, "r");
+  if(fp)
+    {
+      fscanf(fp,"%d",&policy_version);
+      fclose(fp); 
+    }
+  
+  fp = fopen(SELINUX_ENFORCE_FILE, "r");
+  if(fp)
+    {
+      fscanf(fp,"%d",enforce);
+      fclose(fp); 
+    }
+  else {
+    log(L_VB,  "Can't open '%s':  %s\n",
+	    SELINUX_ENFORCE_FILE, strerror(errno));
+    goto UMOUNT;
+  }
+  snprintf(policy_file,sizeof(policy_file),"%s.%d",POLICY_FILE,policy_version);
+  fd = open(policy_file, O_RDONLY);
+  if (fd < 0) {
+    log(L_VB,  "Can't open '%s':  %s\n",
+	    policy_file, strerror(errno));
+    goto UMOUNT;
+  }
+  
+  if (fstat(fd, &sb) < 0) {
+    log(L_VB, "Can't stat '%s':  %s\n",
+	    policy_file, strerror(errno));
+    goto UMOUNT;
+  }
+  
+  map = mmap(NULL, sb.st_size, PROT_READ, MAP_SHARED, fd, 0);
+  if (map == MAP_FAILED) {
+    log(L_VB,  "Can't map '%s':  %s\n",
+	    policy_file, strerror(errno));
+    goto UMOUNT;
+  }
+  ret=security_load_policy(map, sb.st_size);
+  if (ret < 0) {
+    log(L_VB, "security_load_policy failed\n");
+  }
+
+ UMOUNT:
+  umount(SELINUXMNT); 
+  return(ret);
+}
+#endif
 
 /* Version information */
 char *Version = "@(#) init " VERSION "  " DATE "  miquels@cistron.nl";
@@ -2576,6 +2657,20 @@
 		maxproclen += strlen(argv[f]) + 1;
 	}
 
+#ifdef WITH_SELINUX
+  	if (getenv("SELINUX_INIT") == NULL) {
+	  putenv("SELINUX_INIT=YES");
+	  int enforce=0;
+	  if (load_policy(&enforce) == 0 ) {
+	    execv(myname, argv);
+	  } else {
+	    if (enforce) 
+	      /* SELinux in enforcing mode but load_policy failed */
+	      exit(1);
+	  }
+	}
+#endif
+  
 	/* Start booting. */
 	argv0 = argv[0];
 	argv[1] = NULL;
--- sysvinit-2.85/src/Makefile.selinux	2003-10-21 11:01:52.000000000 -0400
+++ sysvinit-2.85/src/Makefile	2003-10-21 11:01:52.000000000 -0400
@@ -32,7 +32,7 @@
 all:		$(PROGS)
 
 init:		init.o init_utmp.o
-		$(CC) $(LDFLAGS) $(STATIC) -o $@ init.o init_utmp.o
+		$(CC) $(LDFLAGS) $(STATIC) -o $@ init.o init_utmp.o -lselinux
 
 halt:		halt.o ifdown.o hddown.o utmp.o reboot.h
 		$(CC) $(LDFLAGS) -o $@ halt.o ifdown.o hddown.o utmp.o
@@ -62,7 +62,7 @@
 		$(CC) $(LDFLAGS) -o $@ bootlogd.o
 
 init.o:		init.c init.h set.h reboot.h
-		$(CC) -c $(CFLAGS) init.c
+		$(CC) -c $(CFLAGS) -DWITH_SELINUX init.c
 
 utmp.o:		utmp.c init.h
 		$(CC) -c $(CFLAGS) utmp.c

Re: init patch for loading policy

[Stephen Smalley]

On Tue, 2003-10-21 at 14:07, Daniel J Walsh wrote:
> Here is my patch to init to load initial policy.

> +#define POLICY_FILE "/etc/security/selinux/policy"
> +#define DEFAULT_POLICY_VERSION 15
> +#define SELINUXMNT "/selinux"
> +#define POLICY_VERSION_FILE "/selinux/policyvers"
> +#define SELINUX_ENFORCE_FILE "/selinux/enforce"

We should likely encapsulate these definitions in libselinux, and
provide functions for obtaining them, rather than hardcoding them in
/sbin/init.

-- 
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: init patch for loading policy

[Stephen Smalley]

On Tue, 2003-10-21 at 14:54, Stephen Smalley wrote:
> On Tue, 2003-10-21 at 14:07, Daniel J Walsh wrote:
> > Here is my patch to init to load initial policy.
> 
> > +#define POLICY_FILE "/etc/security/selinux/policy"
> > +#define DEFAULT_POLICY_VERSION 15
> > +#define SELINUXMNT "/selinux"
> > +#define POLICY_VERSION_FILE "/selinux/policyvers"
> > +#define SELINUX_ENFORCE_FILE "/selinux/enforce"
> 
> We should likely encapsulate these definitions in libselinux, and
> provide functions for obtaining them, rather than hardcoding them in
> /sbin/init.

I've added such functions and definitions to libselinux.

-- 
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: init patch for loading policy

[Stephen Smalley]

On a related note, someone else pointed out via private email that
initramfs could be used with 2.6 for the initial policy load, and this
wouldn't require any bootloader support.  That would avoid the legacy
bootloader problems while still preserving the desirable aspects of an
early policy load.

-- 
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: init patch for loading policy

[Russell Coker]

On Tue, 21 Oct 2003 22:32, Stephen Smalley wrote:
> On a related note, someone else pointed out via private email that
> initramfs could be used with 2.6 for the initial policy load, and this
> wouldn't require any bootloader support.  That would avoid the legacy
> bootloader problems while still preserving the desirable aspects of an
> early policy load.

For the long term this is probably the best solution.  It avoids all the 
hackery we are going through now, and has no down-side.

I will clean up my initrd-policy for release then.  For the policy needed to 
get to the stage of running init and letting it load a proper policy to do 
the rest I can probably get it to below 100K uncompressed (probably <20K 
compressed).

My last experiments were at about 300K uncompressed, but that was for having 
the real SE Linux policy loaded from a script under /etc/rc.d/rc5.d.  So I 
had to have policy for updfstab, fsck, and lots of other things.  All that 
policy raised the potential for changes and also made the policy big.  Having 
the bare minimum for init_t and initrc_t will make it much smaller and a good 
candidate for linking in the kernel.

-- 
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: init patch for loading policy

[Bastian Blank]

On Mon, Oct 20, 2003 at 01:48:15AM +1000, Russell Coker wrote:
> I've attached a patch for /sbin/init to load the policy and set enforcing 
> mode.  Here's a quick summary of the algorithm:

isn't it easier to divert /sbin/init and use a script which loads the
policy and execs the real init after?

bastian


--
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: init patch for loading policy

[Russell Coker]

On Tue, 21 Oct 2003 06:47, Bastian Blank wrote:
> On Mon, Oct 20, 2003 at 01:48:15AM +1000, Russell Coker wrote:
> > I've attached a patch for /sbin/init to load the policy and set enforcing
> > mode.  Here's a quick summary of the algorithm:
>
> isn't it easier to divert /sbin/init and use a script which loads the
> policy and execs the real init after?

No.  You have all the same issues, with the additional problem that the shell 
which is used to interpret the script might do something unexpected (like 
closing file handle 11) and break init functionality.

I've tested out making a diversion for /sbin/init, it basically works, but I 
don't think it's a good solution.

Another method I considered is to have a script named /sbin/se-init which 
loads policy and exec's /sbin/init.  Then you would configure your boot 
loader to pass "init=/sbin/se-init" to the kernel.  I have used this for UML 
systems and it basically works.  However I am concerned about what happens if 
init SEGV's...

-- 
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: init patch for loading policy

[Bastian Blank]

On Tue, Oct 21, 2003 at 10:57:54AM +1000, Russell Coker wrote:
> > isn't it easier to divert /sbin/init and use a script which loads the
> > policy and execs the real init after?
> 
> No.  You have all the same issues, with the additional problem that the shell 
> which is used to interpret the script might do something unexpected (like 
> closing file handle 11) and break init functionality.

This pipe is only used for reexec. The reexec uses argv[0] as
executable, which is the real one, not the script.

> Another method I considered is to have a script named /sbin/se-init which 
> loads policy and exec's /sbin/init.  Then you would configure your boot 
> loader to pass "init=/sbin/se-init" to the kernel.  I have used this for UML 
> systems and it basically works.  However I am concerned about what happens if 
> init SEGV's...

That is exactly the same because at least any sysvinit versions i know
don't rely on the real name /sbin/init.

Bastian

-- 
Ahead warp factor one, Mr. Sulu.

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