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 ...
[ message continues ]

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 

ITYM contexts :-)



- James
-- 
James Morris
<jmorris@namei.org>
--

[ message continues ]

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

Oops again - that whole block should be removed as it was there
because the contexts file was created in a different step, which
it isn't any more.

thanks,
-serge

From 04d2ff138858dd997ec521ca6c74493259045bcc Mon Sep 17 00:00:00 2001
From: Serge Hallyn <serue@us.ibm.com>
Date: Fri, 22 Aug 2008 13:38:13 -0500
Subject: [PATCH 1/1] selinux: add support for installing a dummy policy

In August 2006 I posted a patch generating a minimal SELinux policy.  This
week, David P. Quigley posted an updated version of that as a patch against
the kernel.  It 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?

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

se 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 ...
[ message continues ]

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


- James
-- 
James Morris
<jmorris@namei.org>
--

[ message continues ]

In that case, we really ought to have a general introduction to SELinux
there first, and then include description of this dummy policy and a
pointer to the reference policy as part of that text.

-- 
Stephen Smalley
National Security Agency

--

[ message continues ]

ext4, ext4dev, gfs2 too.

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

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?

-- 
Stephen Smalley
National Security Agency

--

[ message continues ]

Thanks for reviewing, Stephen.


I'm testing a version which uses fixfiles, but it complains about
the fact that selinux is not loaded.  Using setfiles seemed
more robust.  So I guess I'll go back to that for now.  Someone

Done in my new version (which I'll send out once I re-create
it using setfiles again), along with most of your other

This (like the whole file) came from David, but nevertheless it's
something I've had to do many times to get a system booted.  Maybe the
new fedora initrd way of enabling selinux changes that, but it would

I was going to just explain how to do it in the documentation, but went
ahead and modified install_policy.sh to do it.

New version coming soon.

thanks,
-serge
--

[ message continues ]

[Snip...]

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

Signed-off-by: David Quigley <dpquigl@tycho.nsa.gov>

Dave

--

[ message continues ]

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

[ message continues ]

I think the answer to this is not very easy at all. If the reason for
having something like this is to use it as a starting point for very
tiny policies I'm not sure how useful it is. For example lets say you
have an application that uses tmp files and they want to have them
labeled in a way that isolates them from base_t. You now need to
label /tmp so you can have your transition rule on your process type and
tmp_t. This means you now need to grant a bunch of permissions on temp_t
for base_t just to maintain the idea that base_t is completely
unconstrained.

This may seem good enough for some people which is why I resurrected
Serge's patch. I think the better idea would be to look at the way
reference policy is structured and see if it is organized properly. It
might be useful for us to be able to say here is an absolute minimum
policy for things we think are key to a Linux system and allow people to
build their application policies on top of that. This would give the
embedded people a much smaller initial footprint for what they need and
reference or fedora policy can be a set of modules on top of this base.
I know we already have this in the form of the base.pp module and a
bunch of other modules on top of it but I don't see how base.pp is
usable without a whole slew of modules.

Dave

--

[ message continues ]