Enable SELinux via boot parameter

Enable SELinux via boot parameter

[James Morris]

This patch against 2.6.0-test4 adds an 'selinux' boot parameter which must 
be used to actually enable SELinux.  It has been sent to Andrew Morton and 
is also in the NSA tree.

The purpose of the patch is to allow a vendor to ship a single kernel
image with SELinux built-in, without requiring the user to use it.

Without specifying selinux=1 as a boot parameter, SELinux will not
register with LSM and selinuxfs will not be registered as a filesystem.  
This causes SELinux to be bypassed entirely from then on, and no
performance overhead is imposed.  Other security modules may then also be 
loaded if needed.


- James
-- 
James Morris
<jmorris@redhat.com>

diff -urN -X dontdiff linux-2.6.0-test4.orig/security/selinux/hooks.c linux-2.6.0-test4.w1/security/selinux/hooks.c
--- linux-2.6.0-test4.orig/security/selinux/hooks.c	2003-08-23 11:53:14.000000000 +1000
+++ linux-2.6.0-test4.w1/security/selinux/hooks.c	2003-09-02 23:28:48.000000000 +1000
@@ -73,6 +73,15 @@
 __setup("enforcing=", enforcing_setup);
 #endif
 
+int selinux_enabled = 0;
+
+static int __init selinux_enabled_setup(char *str)
+{
+	selinux_enabled = simple_strtol(str, NULL, 0);
+	return 1;
+}
+__setup("selinux=", selinux_enabled_setup);
+
 /* Original (dummy) security module. */
 static struct security_operations *original_ops = NULL;
 
@@ -3354,6 +3363,11 @@
 {
 	struct task_security_struct *tsec;
 
+	if (!selinux_enabled) {
+		printk(KERN_INFO "SELinux:  Not enabled at boot.\n");
+		return 0;
+	}
+
 	printk(KERN_INFO "SELinux:  Initializing.\n");
 
 	/* Set the security state for the initial task. */
diff -urN -X dontdiff linux-2.6.0-test4.orig/security/selinux/Kconfig linux-2.6.0-test4.w1/security/selinux/Kconfig
--- linux-2.6.0-test4.orig/security/selinux/Kconfig	2003-08-11 01:06:37.000000000 +1000
+++ linux-2.6.0-test4.w1/security/selinux/Kconfig	2003-09-02 23:40:36.128086552 +1000
@@ -3,11 +3,14 @@
 	depends on SECURITY
 	default n
 	help
-	  This enables NSA Security-Enhanced Linux (SELinux).
+	  This selects NSA Security-Enhanced Linux (SELinux).
 	  You will also need a policy configuration and a labeled filesystem.
 	  You can obtain the policy compiler (checkpolicy), the utility for
 	  labeling filesystems (setfiles), and an example policy configuration
 	  from http://www.nsa.gov/selinux.
+	  SELinux needs to be explicitly enabled on the kernel command line with
+	  selinux=1.  If you specify selinux=0 or do not use this parameter,
+	  SELinux will not be enabled.
 	  If you are unsure how to answer this question, answer N.
 
 config SECURITY_SELINUX_DEVELOP
diff -urN -X dontdiff linux-2.6.0-test4.orig/security/selinux/selinuxfs.c linux-2.6.0-test4.w1/security/selinux/selinuxfs.c
--- linux-2.6.0-test4.orig/security/selinux/selinuxfs.c	2003-08-11 01:06:37.000000000 +1000
+++ linux-2.6.0-test4.w1/security/selinux/selinuxfs.c	2003-09-02 23:23:02.000000000 +1000
@@ -17,6 +17,8 @@
 #include "security.h"
 #include "objsec.h"
 
+extern int selinux_enabled;
+
 /* Check whether a task is allowed to use a security operation. */
 int task_has_security(struct task_struct *tsk,
 		      u32 perms)
@@ -587,7 +589,7 @@
 
 static int __init init_sel_fs(void)
 {
-	return register_filesystem(&sel_fs_type);
+	return selinux_enabled ? register_filesystem(&sel_fs_type) : 0;
 }
 
 __initcall(init_sel_fs);


--
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: Enable SELinux via boot parameter

[Chris PeBenito]

There is one thing I don't like about this.  SELinux should be by
default on.  You should have to specify that its disabled, rather than
the opposite.  In general if people are compiling their own kernels, and
they want SELinux, they'll want it enabled by default, and shouldn't
need to specify extra kernel parameters.  The distributions shipping one
single kernel is more of a special case.

I think this is one that should be left up to distributions to patch in
themselves.

On Tue, 2003-09-02 at 18:46, James Morris wrote:
> This patch against 2.6.0-test4 adds an 'selinux' boot parameter which must 
> be used to actually enable SELinux.  It has been sent to Andrew Morton and 

> Without specifying selinux=1 as a boot parameter, SELinux will not
> register with LSM and selinuxfs will not be registered as a filesystem.  

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer, SELinux
Hardened Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243

--
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: Enable SELinux via boot parameter

[Brian May]

On Tue, Sep 02, 2003 at 10:07:32PM -0500, Chris PeBenito wrote:
> There is one thing I don't like about this.  SELinux should be by
> default on.  You should have to specify that its disabled, rather than
> the opposite.  In general if people are compiling their own kernels, and
> they want SELinux, they'll want it enabled by default, and shouldn't
> need to specify extra kernel parameters.  The distributions shipping one
> single kernel is more of a special case.

I don't see this as being a big problem, just that existing selinux
users will need to change lilo.conf or whatever to add the extra
parameter.

I think adding this extra parameter (whatever the default happens to be)
is a good thing, it means you can still boot even if the selinux policy
gets badly broken (eg.  due to disk curruption), or just breaks root
logins for instance.
-- 
Brian May <bam@snoopy.apana.org.au>

--
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: Enable SELinux via boot parameter

[Tom]

On Tue, Sep 02, 2003 at 10:07:32PM -0500, Chris PeBenito wrote:
> There is one thing I don't like about this.  SELinux should be by
> default on.  You should have to specify that its disabled, rather than
> the opposite.  In general if people are compiling their own kernels, and
> they want SELinux, they'll want it enabled by default, and shouldn't
> need to specify extra kernel parameters.  The distributions shipping one
> single kernel is more of a special case.

The broad public will not be using SELinux for now, so I'm afraid it's
not really a special case.

There should, however, be a kernel config option to turn it on by
default and FORCE it on. (i.e. no way to boot that kernel without SE
enabled). Otherwise we have a trivial boot security problem.

I know securing physical access to the system isn't really the scope of
SE, but it shouldn't be THAT easy.



-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: Enable SELinux via boot parameter

[Stephen Smalley]

On Tue, 2003-09-02 at 23:07, Chris PeBenito wrote:
> There is one thing I don't like about this.  SELinux should be by
> default on.  You should have to specify that its disabled, rather than
> the opposite.  In general if people are compiling their own kernels, and
> they want SELinux, they'll want it enabled by default, and shouldn't
> need to specify extra kernel parameters.  The distributions shipping one
> single kernel is more of a special case.
> 
> I think this is one that should be left up to distributions to patch in
> themselves.

We considered this option, but decided it would be preferable to provide
a consistent behavior for upstream and distributions to avoid user
confusion when moving between upstream kernels and distribution kernels.
It isn't that different from having to specify "enforcing=1" to enable
enforcing mode when development support is enabled.  It is true that you
can disable development support, but how many people actually do so?
 
-- 
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: Enable SELinux via boot parameter

[Stephen Smalley]

On Wed, 2003-09-03 at 03:12, Tom wrote:
> The broad public will not be using SELinux for now, so I'm afraid it's
> not really a special case.
> 
> There should, however, be a kernel config option to turn it on by
> default and FORCE it on. (i.e. no way to boot that kernel without SE
> enabled). Otherwise we have a trivial boot security problem.
> 
> I know securing physical access to the system isn't really the scope of
> SE, but it shouldn't be THAT easy.

It is already the case that you need to specify 'enforcing=1' to boot an
enforcing kernel if you enabled development support.  How many people
disable development support?  And if you do disable development support,
do you also keep around a second kernel that you can boot for emergency
recovery?  In that case, what is the difference?  You are still are
relying on your lilo/grub password to limit the ability to boot the
non-SELinux kernel.
 
-- 
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: Enable SELinux via boot parameter

[Tom]

On Wed, Sep 03, 2003 at 08:29:41AM -0400, Stephen Smalley wrote:
> It is already the case that you need to specify 'enforcing=1' to boot an
> enforcing kernel if you enabled development support.  How many people
> disable development support?  

More once SE gets more stable and production systems get deployed.


> And if you do disable development support,
> do you also keep around a second kernel that you can boot for emergency
> recovery?  

Not on a production machine. I'd insist on a from-CD boot there for
recovery.


I'd love to have a way to ensure that if _this_ kernel was booted, it
_does_ use SE.

-- 
PGP/GPG key: http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: Enable SELinux via boot parameter

[Chris PeBenito]

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

On Wed, 2003-09-03 at 07:29, Stephen Smalley wrote:
> On Wed, 2003-09-03 at 03:12, Tom wrote:
> > The broad public will not be using SELinux for now, so I'm afraid it's
> > not really a special case.

Yes, but that doesn't invalidate the idea that this in effect penalizes
people that do use it.  Most of these people compile their own kernels,
meaning they choose SELinux, and expect it to be on by default.  Making
the default off caters to the needs of distributions rather than the
needs of SELinux users.  Just because SELinux users are in the minority
doesn't mean they should loose out to distribution's needs.

> > There should, however, be a kernel config option to turn it on by
> > default and FORCE it on. (i.e. no way to boot that kernel without SE
> > enabled). Otherwise we have a trivial boot security problem.

I like this.  Except the option should be to make it disable-able. 
Kinda like how turning on development mode requires to specify
enforcing=1 to boot up in enforcing.

> It is already the case that you need to specify 'enforcing=1' to boot an
> enforcing kernel if you enabled development support.  How many people
> disable development support?  And if you do disable development support,
> do you also keep around a second kernel that you can boot for emergency
> recovery?  In that case, what is the difference?  You are still are
> relying on your lilo/grub password to limit the ability to boot the
> non-SELinux kernel.

This is true; however, from my point of view, it supports having a
kernel config option.  If development is not turned on, then it always
enforces.  If no one ever turns off development mode, as you're arguing,
then why bother making it an option, and just make it default to
development mode?  By not making this SELinux-disabling option
controlled by a kernel config option, you are eliminating the usefulness
of regular (non-development) mode.  If you do turn off development,
SELinux could still be disabled by this patch, so it makes
non-development meaningless.  Lilo/grub passwords not being real
security does not negate this fact.  Anyone that has physical access to
a machine can generally do whatever they want anyway.

My suggestion is the default should be to not be able to disable
selinux, and have a kernel config option to make it disable-able (and
with that turned on SELinux would be disabled by default).  I think this
is a good compromise between people that compile their on kernels and
just want SELinux to work by default, and also gives distributions the
option of having a kernel that SELinux is disabled by default.

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer, SELinux
Hardened Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Enable SELinux via boot parameter

[James Morris]

On Wed, 3 Sep 2003, Tom wrote:

> I'd love to have a way to ensure that if _this_ kernel was booted, it
> _does_ use SE.


Ok, the patch below (against 2.6.0-test4-mm5) makes the boot parameter a 
configuration option (defaulting to N).  Also, the logic is inverted so 
that even with the option enabled, you have to use selinux=0 to bypass 
SELinux.

This seems to be a safer approach: two explicit actions (one compile time
and one runtime) are thus required to disable SELinux if it has been
configured for the kernel image.

This should also address the consistency issue where various kernels may
or may not provide the boot parameter option (i.e. you will never need to 
use selinux=1 to enable SELinux).

Comments?

- James
-- 
James Morris
<jmorris@redhat.com>

diff -urN -X dontdiff linux-2.6.0-test4-mm5.orig/security/selinux/hooks.c linux-2.6.0-test4-mm5.w1/security/selinux/hooks.c
--- linux-2.6.0-test4-mm5.orig/security/selinux/hooks.c	2003-09-04 01:48:01.000000000 +1000
+++ linux-2.6.0-test4-mm5.w1/security/selinux/hooks.c	2003-09-04 02:08:21.340250584 +1000
@@ -73,7 +73,8 @@
 __setup("enforcing=", enforcing_setup);
 #endif
 
-int selinux_enabled = 0;
+#ifdef CONFIG_SECURITY_SELINUX_BOOTPARAM
+int selinux_enabled = 1;
 
 static int __init selinux_enabled_setup(char *str)
 {
@@ -81,6 +82,7 @@
 	return 1;
 }
 __setup("selinux=", selinux_enabled_setup);
+#endif
 
 /* Original (dummy) security module. */
 static struct security_operations *original_ops = NULL;
@@ -3357,7 +3359,7 @@
 	struct task_security_struct *tsec;
 
 	if (!selinux_enabled) {
-		printk(KERN_INFO "SELinux:  Not enabled at boot.\n");
+		printk(KERN_INFO "SELinux:  Disabled at boot.\n");
 		return 0;
 	}
 
diff -urN -X dontdiff linux-2.6.0-test4-mm5.orig/security/selinux/include/security.h linux-2.6.0-test4-mm5.w1/security/selinux/include/security.h
--- linux-2.6.0-test4-mm5.orig/security/selinux/include/security.h	2003-08-11 01:06:37.000000000 +1000
+++ linux-2.6.0-test4-mm5.w1/security/selinux/include/security.h	2003-09-04 02:03:53.000000000 +1000
@@ -14,6 +14,12 @@
 
 #define SELINUX_MAGIC 0xf97cff8c
 
+#ifdef CONFIG_SECURITY_SELINUX_BOOTPARAM
+extern int selinux_enabled;
+#else
+#define selinux_enabled 1
+#endif
+
 int security_load_policy(void * data, size_t len);
 
 struct av_decision {
diff -urN -X dontdiff linux-2.6.0-test4-mm5.orig/security/selinux/Kconfig linux-2.6.0-test4-mm5.w1/security/selinux/Kconfig
--- linux-2.6.0-test4-mm5.orig/security/selinux/Kconfig	2003-09-04 01:48:01.000000000 +1000
+++ linux-2.6.0-test4-mm5.w1/security/selinux/Kconfig	2003-09-04 02:11:35.884675336 +1000
@@ -8,11 +8,22 @@
 	  You can obtain the policy compiler (checkpolicy), the utility for
 	  labeling filesystems (setfiles), and an example policy configuration
 	  from http://www.nsa.gov/selinux.
-	  SELinux needs to be explicitly enabled on the kernel command line with
-	  selinux=1.  If you specify selinux=0 or do not use this parameter,
-	  SELinux will not be enabled.
 	  If you are unsure how to answer this question, answer N.
 
+config SECURITY_SELINUX_BOOTPARAM
+	bool "NSA SELinux boot parameter"
+	depends on SECURITY_SELINUX
+	default n
+	help
+	  This option adds a kernel parameter 'selinux', which allows SELinux
+	  to be disabled at boot.  If this option is selected, SELinux
+	  functionality can be disabled with selinux=0 on the kernel
+	  command line.  The purpose of this option is to allow a single
+	  kernel image to be distributed with SELinux built in, but not
+	  necessarily enabled.
+	  
+	  If you are unsure how to answer this question, answer N.
+	  
 config SECURITY_SELINUX_DEVELOP
 	bool "NSA SELinux Development Support"
 	depends on SECURITY_SELINUX
diff -urN -X dontdiff linux-2.6.0-test4-mm5.orig/security/selinux/selinuxfs.c linux-2.6.0-test4-mm5.w1/security/selinux/selinuxfs.c
--- linux-2.6.0-test4-mm5.orig/security/selinux/selinuxfs.c	2003-09-04 01:48:01.000000000 +1000
+++ linux-2.6.0-test4-mm5.w1/security/selinux/selinuxfs.c	2003-09-04 01:53:58.000000000 +1000
@@ -17,8 +17,6 @@
 #include "security.h"
 #include "objsec.h"
 
-extern int selinux_enabled;
-
 /* Check whether a task is allowed to use a security operation. */
 int task_has_security(struct task_struct *tsk,
 		      u32 perms)


--
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: Enable SELinux via boot parameter

[Tom]

On Wed, Sep 03, 2003 at 12:31:04PM -0400, James Morris wrote:
> Comments?

Tom.Status = "happy" ;)


Maybe we should actually ask a distro or two what they think, though. I
don't know if there is a weird reason (like a policy to have no boot
parameters for the default kernel or whatever) that they'd object
heavily.

-- 
http://web.lemuria.org/pubkey.html
pub  1024D/2D7A04F5 2002-05-16 Tom Vogt <tom@lemuria.org>
     Key fingerprint = C731 64D1 4BCF 4C20 48A4  29B2 BF01 9FA1 2D7A 04F5

--
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: Enable SELinux via boot parameter

[Chris PeBenito]

On Wed, 2003-09-03 at 12:54, Tom wrote:
> On Wed, Sep 03, 2003 at 12:31:04PM -0400, James Morris wrote:
> > Comments?
> 
> Tom.Status = "happy" ;)
> 
> 
> Maybe we should actually ask a distro or two what they think, though. I
> don't know if there is a weird reason (like a policy to have no boot
> parameters for the default kernel or whatever) that they'd object
> heavily.

Looks good to me too.

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer, SELinux
Hardened Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243

--
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: Enable SELinux via boot parameter

[Russell Coker]

On Thu, 4 Sep 2003 03:54, Tom wrote:
> Maybe we should actually ask a distro or two what they think, though.

That's been done.  James and I are employed by Red Hat, and I also represent 
the interests of the Debian project when it comes to SE Linux kernel issues.

All of the options that we discussed seemed OK to me for Debian.  I don't 
think it's much of a big deal.  Having a distribution kernel with minor 
variations from the kernel.org kernel is expected, so whether things default 
to on or off doesn't matter too much IMHO.

Distributions which don't like the idea can always patch it out.

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