selinux: add support for installing a dummy policy

In August 2006 I posted a patch to the selinux list generating a minimal SELinux policy. This week, David P. Quigley posted an updated version of that as a patch against the kernel. In addition to some fixes, also had nice logic for auto-installing the policy.

I've gone ahead and hooked it into the kernel Makefile logic. The way I have it here, doing 'make scripts' ends up compiling 'mdp', after which you must
cd scripts/selinux
sh install_policy.sh

That isn't as nice as being able to do
make selinux_install
the way David had it, but it avoids mucking with the top-level Makefile. Which is preferred?

Quoted 11 lines · Serge E. Hallyn

In August 2006 I posted a patch to the selinux list generating a minimal SELinux policy. This week, David P. Quigley posted an updated version of that as a patch against the kernel. In addition to some fixes, also had nice logic for auto-installing the policy.

I've gone ahead and hooked it into the kernel Makefile logic. The way I have it here, doing 'make scripts' ends up compiling 'mdp', after which you must
cd scripts/selinux
sh install_policy.sh

Quoted 4 lines

That isn't as nice as being able to do
make selinux_install
the way David had it, but it avoids mucking with the top-level Makefile. Which is preferred?

I think leaving out of the top level makefile is preferred, as there are no other subsystem targets there.

Please make sure 'make distclean' cleans up properly. These are currently left behind:

#       scripts/selinux/mdp/file_contexts
#       scripts/selinux/mdp/policy.23
#       scripts/selinux/mdp/policy.conf

Please also provide documentation on how to boot the system up with this policy.

Review

Quoted 1 line

(quoted diff) +1 -0

+	echo "no file contests file.  Please run"

ITYM contexts :-)

Good point. Where would people who'd want to use this be most likely to look, in a scripts/selinux/README, or in Documentation/selinux or Documentation/security/selinux or somesuch?

Quoted 4 lines · Serge E. Hallyn

Good point. Where would people who'd want to use this be most likely to look, in a scripts/selinux/README, or in Documentation/selinux or Documentation/security/selinux or somesuch?

There's Smack documentation under Documentation/, so perhaps next to that, with a pointer to it in scripts/selinux/README.

scripts/selinux/install_policy.sh line 9

Quoted 12 lines · Serge E. Hallyn

scripts/selinux/install_policy.sh new file +9 -0

@@ -0,0 +1,44 @@
+#!/bin/sh
+if [ `id -u` -ne 0 ]; then
+	echo "$0: must be root to install the selinux policy"
+	exit 1
+fi
+SF=`which setfiles`
+if [ $? -eq 1 ]; then
+	if [ -f /usr/sbin/setfiles ]; then
+		SF="/usr/sbin/setfiles"

/sbin/setfiles on modern Fedora releases.

scripts/selinux/install_policy.sh line 20

Quoted 11 lines

scripts/selinux/install_policy.sh new file +11 -0

+	else
+		echo "no selinux tools installed: setfiles"
+		exit 1
+	fi
+fi
+
+cd mdp
+
+CP=`which checkpolicy`
+./mdp policy.conf file_contexts
+$CP -o policy.`checkpolicy -V | awk '{print $1}'` policy.conf

Save version to a variable and reuse below.

scripts/selinux/install_policy.sh line 33

Quoted 13 lines

scripts/selinux/install_policy.sh new file +13 -0

+
+mkdir -p /etc/selinux/dummy/policy
+mkdir -p /etc/selinux/dummy/contexts/files
+
+cp file_contexts /etc/selinux/dummy/contexts/files
+cp dbus_contexts /etc/selinux/dummy/contexts
+cp policy.`checkpolicy -V | awk '{print $1}'` /etc/selinux/dummy/policy
+FC_FILE=/etc/selinux/dummy/contexts/files/file_contexts
+
+cd /etc/selinux/dummy/contexts/files
+$SF file_contexts /
+
+mounts=`cat /proc/$$/mounts | egrep "ext2|ext3|xfs|jfs" | awk '{ print $2 '}`

ext4, ext4dev, gfs2 too.
See /sbin/fixfiles for an example. Or run it.

scripts/selinux/install_policy.sh line 36

Quoted 3 lines

scripts/selinux/install_policy.sh new file +3 -0

+for line in $mounts; do
+	$SF file_contexts $line
+done

You can pass them all to setfiles at once; it takes a list of mount points after the file_contexts file. Or run fixfiles instead as it does much the same.

However, I don't believe this step will work if you are doing this on an existing SELinux-enabled system - the kernel will check the contexts upon setxattr against the active policy and reject them, and you haven't loaded the new policy yet. Also, this is a "destructive" operation, i.e. if they were running SELinux before, they are hereby clobbering all their file labels. Possibly you should bail out if selinuxenabled (utility that can be used as a boolean in shell conditionals). if /usr/sbin/selinuxenabled; then
echo"SELinux already enabled with a policy loaded; exiting." exit 1
fi

scripts/selinux/install_policy.sh line 43

Quoted 7 lines

scripts/selinux/install_policy.sh new file +7 -0

+
+dodev=`cat /proc/$$/mounts | grep "/dev "`
+if [ "eq$dodev" != "eq" ]; then
+	mount --move /dev /mnt
+	$SF file_contexts /dev
+	mount --move /mnt /dev
+fi

Not sure what you are doing here. If /dev is udev-managed, then it will

handle labeling at boot. But it still shows up as a tmpfs mount in /proc/self/mounts.

Where do you set up /etc/selinux/config to refer to this dummy policy so it will get loaded at boot?

In August 2006 I posted a patch to the selinux list generating a minimal SELinux policy. This week, David P. Quigley posted an updated version of that as a patch against the kernel. In addition to some fixes, also had nice logic for auto-installing the policy.

I've gone ahead and hooked it into the kernel Makefile logic. The way I have it here, doing 'make scripts' ends up compiling 'mdp', after which you must
cd scripts/selinux
sh install_policy.sh

That isn't as nice as being able to do
make selinux_install
the way David had it, but it avoids mucking with the top-level Makefile. Which is preferred?

In any case, this seems like a good thing to have in the kernel tree, to facilitate simple selinux boot tests.

Following is David's original patch intro (preserved especially bc it has stats on the generated policies):

======================================================================
For those interested in the changes there were only two significant changes. The first is that the iteration through the list of classes used NULL as a sentinel value. The problem with this is that the class_to_string array actually has NULL entries in its table as place holders for the user space object classes.

The second change was that it would seem at some point the initial sids table was NULL terminated. This is no longer the case so that iteration has to be done on array length instead of looking for NULL.

Some statistics on the policy that it generates:

The policy consists of 523 lines which contain no blank lines. Of those 523 lines 453 of them are class, permission, and initial sid definitions. These lines are usually little to no concern to the policy developer since they will not be adding object classes or permissions. Of the remaining 70 lines there is one type, one role, and one user statement. The remaining lines are broken into three portions. The first group are TE allow rules which make up 29 of the remaining lines, the second is assignment of labels to the initial sids which consist of 27 lines, and file system labeling statements which are the remaining 11.

In addition to the policy.conf generated there is a single file_contexts file containing two lines which labels the entire system with base_t.

This policy generates a policy.23 binary that is 7920 bytes.
======================================================================
(then a few versions later...):
======================================================================
The new policy is 587 lines (stripped of blank lines) with 476 of those lines being the boilerplate that I mentioned last time. The remaining 111 lines have the 3 lines for type, user, and role, 70 lines for the allow rules (one for each object class including user space object classes), 27 lines to assign types to the initial sids, and 11 lines for file system labeling. The policy binary is 9194 bytes.
======================================================================

Signed-off-by Serge Hallyn <[email protected]>

Quoted 60 lines · Serge E. Hallyn

In August 2006 I posted a patch to the selinux list generating a minimal SELinux policy. This week, David P. Quigley posted an updated version of that as a patch against the kernel. In addition to some fixes, also had nice logic for auto-installing the policy.

I've gone ahead and hooked it into the kernel Makefile logic. The way I have it here, doing 'make scripts' ends up compiling 'mdp', after which you must
cd scripts/selinux
sh install_policy.sh

That isn't as nice as being able to do
make selinux_install
the way David had it, but it avoids mucking with the top-level Makefile. Which is preferred?

In any case, this seems like a good thing to have in the kernel tree, to facilitate simple selinux boot tests.

Following is David's original patch intro (preserved especially bc it has stats on the generated policies):

======================================================================
For those interested in the changes there were only two significant changes. The first is that the iteration through the list of classes used NULL as a sentinel value. The problem with this is that the class_to_string array actually has NULL entries in its table as place holders for the user space object classes.

The second change was that it would seem at some point the initial sids table was NULL terminated. This is no longer the case so that iteration has to be done on array length instead of looking for NULL.

Some statistics on the policy that it generates:

The policy consists of 523 lines which contain no blank lines. Of those 523 lines 453 of them are class, permission, and initial sid definitions. These lines are usually little to no concern to the policy developer since they will not be adding object classes or permissions. Of the remaining 70 lines there is one type, one role, and one user statement. The remaining lines are broken into three portions. The first group are TE allow rules which make up 29 of the remaining lines, the second is assignment of labels to the initial sids which consist of 27 lines, and file system labeling statements which are the remaining 11.

In addition to the policy.conf generated there is a single file_contexts file containing two lines which labels the entire system with base_t.

This policy generates a policy.23 binary that is 7920 bytes.
======================================================================
(then a few versions later...):
======================================================================
The new policy is 587 lines (stripped of blank lines) with 476 of those lines being the boilerplate that I mentioned last time. The remaining 111 lines have the 3 lines for type, user, and role, 70 lines for the allow rules (one for each object class including user space object classes), 27 lines to assign types to the initial sids, and 11 lines for file system labeling. The policy binary is 9194 bytes.
======================================================================

Quoted 1 line

Signed-off-by Serge Hallyn <[email protected]>

[Snip...]

I'm not sure if I have to sign off on this but just in case.

Signed-off-by David Quigley <[email protected]>

Dave

--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.

Quoted 69 lines · David P. Quigley

Quoted 60 lines · Serge E. Hallyn

In August 2006 I posted a patch to the selinux list generating a minimal SELinux policy. This week, David P. Quigley posted an updated version of that as a patch against the kernel. In addition to some fixes, also had nice logic for auto-installing the policy.

I've gone ahead and hooked it into the kernel Makefile logic. The way I have it here, doing 'make scripts' ends up compiling 'mdp', after which you must
cd scripts/selinux
sh install_policy.sh

That isn't as nice as being able to do
make selinux_install
the way David had it, but it avoids mucking with the top-level Makefile. Which is preferred?

In any case, this seems like a good thing to have in the kernel tree, to facilitate simple selinux boot tests.

Following is David's original patch intro (preserved especially bc it has stats on the generated policies):

======================================================================
For those interested in the changes there were only two significant changes. The first is that the iteration through the list of classes used NULL as a sentinel value. The problem with this is that the class_to_string array actually has NULL entries in its table as place holders for the user space object classes.

The second change was that it would seem at some point the initial sids table was NULL terminated. This is no longer the case so that iteration has to be done on array length instead of looking for NULL.

Some statistics on the policy that it generates:

The policy consists of 523 lines which contain no blank lines. Of those 523 lines 453 of them are class, permission, and initial sid definitions. These lines are usually little to no concern to the policy developer since they will not be adding object classes or permissions. Of the remaining 70 lines there is one type, one role, and one user statement. The remaining lines are broken into three portions. The first group are TE allow rules which make up 29 of the remaining lines, the second is assignment of labels to the initial sids which consist of 27 lines, and file system labeling statements which are the remaining 11.

In addition to the policy.conf generated there is a single file_contexts file containing two lines which labels the entire system with base_t.

This policy generates a policy.23 binary that is 7920 bytes.
======================================================================
(then a few versions later...):
======================================================================
The new policy is 587 lines (stripped of blank lines) with 476 of those lines being the boilerplate that I mentioned last time. The remaining 111 lines have the 3 lines for type, user, and role, 70 lines for the allow rules (one for each object class including user space object classes), 27 lines to assign types to the initial sids, and 11 lines for file system labeling. The policy binary is 9194 bytes.
======================================================================

Quoted 1 line

Signed-off-by Serge Hallyn <[email protected]>

[Snip...]

I'm not sure if I have to sign off on this but just in case.

Signed-off-by David Quigley <[email protected]>

Quoted 7 lines

Dave

--
This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to [email protected] with the words "unsubscribe selinux" without quotes as the message.

How easy would it be to go from this dummy policy to a policy that confined only one application? IE If I wanted to pull in the bind policy, what would be needed.

This is a question that often comes up. I don't want anything confined except this one app?

I would figure syslog would be a problem right off, others?