[patch] enhanced MLS support

[patch] enhanced MLS support

[Darrel Goeddel]

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

Hello,
     I have attached patches which provides many enhancements to the MLS support
within SELinux - highlights are listed below.  The patches a are against the
latest sourceforge CVS tree.  The kern-0117.patch applies to the nsa/linux-2.6
tree and the usr-0117.patch applies to the nsa/selinux-usr tree.  We have been
using this code for a while and have had several set of eyes go over it - we are
now presenting this for inclusion into the mainline SELinux tree.  We appreciate
all feedback and will attempt to answer all questions.

Thanks.

Darrel

Replaced the existing MLS logic with a flexible system based on the current
constraints language.  The constraints were extended to include operations for
levels.  This allows for configurable overrides of MLS policy rather than using
the previous hardcoded attributes.  It also allows for a more flexible MLS
policy: you can choose a strict BLP model or a modified BLP model which does
not allow write-up, you can limit a class to be "single level", etc...  The
"constrain" and "validatetrans" (see next item) statements are mirrored by the
"mlsconstrain" and "mlsvalidatetrans" statements.  They use the same code for
everything, they just live in different files (constraints vs. mls).

Added validatetrans statements to the policy which are used along with
constraints.  The syntax for these statements is the same the syntax for
constraints with three additional expressions available: "u3 op names",
"r3 op names", and "t3 op names".  For these rules, the *1 tokens refer to the
"old context", the *2 tokens refer to the "new context", and the *3 tokens
refer to the "process context".  These rules are currently only processed for
the file classes (file, dir, lnk_file, ...) by calling the new
security_validate_transition function in the selinux_inode_setxattr hook.  These
rules allow checking process attributes (*3) along with the current object
context (*1) and the proposed object context (*2).  With these rules, one
can require different things of the process based on the relationship of the
objects old and new contexts.  This allows MLS upgrade and downgrade checks
when relabeling an object.

The MLS levels of a subject are used as a sensitivity level (low) and a
clearance (high).  The user MLS properties have accordingly been modified from
a list of ranges to a default level and an allowable range.  The high of the
allowable range acts as the process clearance, and the default levels

The compile time options for MLS support have been replaced with runtime
options/detection.  This will allow a vendor to ship one set of tools and one
kernel to support both MLS and non-MLS enabled policies.  The kernel will
automatically determine the MLS status of a policy when it is read.  MLS
specific checks will be short-circuited if a non-MLS policy is being used.
Checkpolicy now uses the "-M" option to work with MLS policies.  Libsepol will
will automatically determine the status of MLS support when a policy is read
(like the kernel).  There is also a interface to set the MLS status - this is
used when checkpolicy is writing the policy.

The binary policy version was incremented to accommodate these changes.  The
userspace tools and the kernel will still work with older non-MLS binary
polices.  Checkpolicy (and libsepol) can still work with and create older
non-MLS binary policies and the kernel can still use older non-MLS binary
policies.  Previous versions of binary policies with MLS support can not be
used or created with the new tools/kernel.

[-- Attachment #2: kern-0117.patch.gz --]
[-- Type: application/x-gzip, Size: 15010 bytes --]

Re: [patch] enhanced MLS support

[Darrel Goeddel]

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

Darrel Goeddel wrote:
> Hello,
>     I have attached patches which provide many enhancements to the MLS...

Here is the userland patch.

Darrel

[-- Attachment #2: usr-0117.patch.gz --]
[-- Type: application/x-gzip, Size: 32578 bytes --]

Re: [patch] enhanced MLS support

[Stephen Smalley]

On Mon, 2005-01-17 at 18:16, Darrel Goeddel wrote:
> Darrel Goeddel wrote:
> > Hello,
> >     I have attached patches which provide many enhancements to the MLS...
> 
> Here is the userland patch.

Thanks for contributing this enhanced MLS support.  I've looked over the
code and sent a few comments privately.  I also have (finally) gotten a
FC3-based system up and running with the modified kernel and policy, but
this required several steps and additional modifications to the policy,
which I've included below for anyone else who may want to experiment
with the MLS support.  Note that this wouldn't be necessary for a direct
install of a MLS system, which would be the standard case for real users
of MLS.

Steps for converting an existing SELinux system to one with the enhanced
MLS support (Note: reversing this conversion is likewise difficult, so
I'd only do this on a spare machine unless you plan to stay with MLS):

1) Obviously, apply the patches that Darrel provided for the kernel and
userland, and build and install the modified kernel, libsepol, and
checkpolicy.

2) The userland patch doesn't actually enable MLS in the policy
Makefile, and it doesn't include the full set of changes required to
build a MLS policy.  I'll send separately a policy patch relative to the
userland patch that makes the necessary changes to at least compile a
MLS policy.  This includes adding MLS levels to all security contexts,
updating the policy Makefile to enable MLS support and to install the
policy under /etc/selinux/mls, and adding example level and range
authorizations for each user entry.  Apply the patch or make similar
changes to your policy source tree, build and install the new policy,
and change /etc/selinux/config to set SELINUXTYPE=mls.

3) Boot the new kernel into single user mode with selinux=0.  I
originally just tried booting with enforcing=0, but this was not
sufficient, as the current SELinux module will not allow you to mount a
filesystem if the security context on the root inode is invalid (and it
will be with the MLS policy, as it will lack a MLS level).  We may want
to change this behavior of the SELinux module, as it would also pose a
problem if the context were invalid for any other reason (e.g. if the
type of the root inode is no longer defined or the security context was
corrupted in some manner).

4) Relabel all filesystems, e.g. fixfiles relabel.

5) Unmount each mounted filesystem and manually relabel the mount point
directories.   Otherwise, they will also have an invalid security
context and attempts to mount on them are likely to fail.  Note that you
may need to manually use chcon rather than setfiles or restorecon on
these mount point directories, particularly for /selinux, /proc, and
/sys, as file_contexts specifies <<none>> for these directories to avoid
trying to label the pseudo filesystems mounted on the directories, and
restorecon will immediately bail anyway if it can't detect whether
SELinux is enabled (which requires /proc to be mounted).

6) Reboot and come up with the new kernel in enforcing mode.

7) At this point, you should be able to login and work as usual at the
low level (s0).  Actually doing anything interesting with multiple
levels is a bit more problematic, as there is not a newlevel program yet
and runcon will only work for level changes in permissive mode.  You
would likely need to tweak the authorized range for system_u and change
the default level for a given user in order to directly login with
another level.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: [patch] enhanced MLS support

[Stephen Smalley]

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

This patch relative to your userland patch makes the additional changes
needed to at least compile a MLS policy (based on the strict policy), as
described in my prior email.
-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency

[-- Attachment #2: policy-mls.diff.bz2 --]
[-- Type: application/x-bzip, Size: 34170 bytes --]

Re: [patch] enhanced MLS support

[James Morris]

On Mon, 17 Jan 2005, Darrel Goeddel wrote:

> Replaced the existing MLS logic with a flexible system based on the current
> constraints language.

Do you plan to add support for integrity labels?

What about releasibility labels?

> The compile time options for MLS support have been replaced with runtime
> options/detection.

This looks good from the kernel side, and I don't imagine there will be
any real performance issues with all of the runtime checks, given the base
impact of SELinux.


One technical nit (in both kernel and user code):

+int mls_setup_user_levels(struct context *fromcon, struct user_datum *user,
+                          struct context *usercon)
+{
+       struct mls_level *fromcon_sen = &(fromcon->range.level[0]);
+       struct mls_level *fromcon_clr = &(fromcon->range.level[1]);
+       struct mls_level *user_low = &(user->range.level[0]);
+       struct mls_level *user_clr = &(user->range.level[1]);
+       struct mls_level *user_def = &(user->dfltlevel);
+       struct mls_level *usercon_sen = &(usercon->range.level[0]);
+       struct mls_level *usercon_clr = &(usercon->range.level[1]);
+
+       if (selinux_mls_enabled) {

The mls_level definitions & assignments should be in the conditional
section.


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



--
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: [patch] enhanced MLS support

[Casey Schaufler]

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

> On Mon, 17 Jan 2005, Darrel Goeddel wrote:
> 
> > Replaced the existing MLS logic with a flexible
> system based on the current
> > constraints language.
> 
> Do you plan to add support for integrity labels?

I would think that you couldn't call the
system flexible in any meaningful way if
it couldn't accomodate an integrity policy.
The Trix experience is that Biba integrity
is overkill. A binary integrity policy
distinguishing between TCB and User data and
processes is useful, but going beyond that
adds more complexity than anyone (sane) is
going to want to deal with.

> What about releasibility labels?

Erg. Or handling caveats? Actually, the
above comment regarding the flexibility of
the system applies. If the system can't be
demonstrated to handle these, it probably
isn't very agile.



=====
Casey Schaufler
casey@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: [patch] enhanced MLS support

[Stephen Smalley]

On Sun, 2005-01-23 at 22:40, Casey Schaufler wrote:
> I would think that you couldn't call the
> system flexible in any meaningful way if
> it couldn't accomodate an integrity policy.
> The Trix experience is that Biba integrity
> is overkill. A binary integrity policy
> distinguishing between TCB and User data and
> processes is useful, but going beyond that
> adds more complexity than anyone (sane) is
> going to want to deal with.

TE is preferable for integrity protection.  IMHO, there is no need to
introduce a Biba model to SELinux.

> Erg. Or handling caveats? Actually, the
> above comment regarding the flexibility of
> the system applies. If the system can't be
> demonstrated to handle these, it probably
> isn't very agile.

Should be expressible using the category bitmaps.

-- 
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: [patch] enhanced MLS support

[Casey Schaufler]

--- Stephen Smalley <sds@epoch.ncsc.mil> wrote:

> TE is preferable for integrity protection.

Sorry, my acronym matcher failed on "TE".

> IMHO, there is no need to
> introduce a Biba model to SELinux.

It is probably more trouble than it's worth.

> > Erg. Or handling caveats? Actually, the
> > above comment regarding the flexibility of
> > the system applies. If the system can't be
> > demonstrated to handle these, it probably
> > isn't very agile.
> 
> Should be expressible using the category bitmaps.

You could certainly store handling caveats in
the category bitmaps, but expressing NOFORN
in categories has been tried and does not work.


=====
Casey Schaufler
casey@schaufler-ca.com


		
__________________________________ 
Do you Yahoo!? 
Meet the all-new My Yahoo! - Try it today! 
http://my.yahoo.com 
 


--
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: [patch] enhanced MLS support

[Stephen Smalley]

On Mon, 2005-01-24 at 11:38, Casey Schaufler wrote:
> Sorry, my acronym matcher failed on "TE".

Type Enforcement.  It was originally discussed as an alternative to Biba
in "A Practical Alternative to Hierarchical Integrity Policies", in the
Proceedings of the 8th National Computer Security Conference, 1985,
pages 18-27.

> You could certainly store handling caveats in
> the category bitmaps, but expressing NOFORN
> in categories has been tried and does not work.

I'll leave it to Darrel to respond to this point.

-- 
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: [patch] enhanced MLS support

[Darrel Goeddel]

I have new patches that incorporates feedback that I have received (and some 
things that I noticed).  There is some code cleanup, and some bugfixes that 
never made their way into the the MLS code before.  The most noticeable change 
is the addition of the "-l" option to newrole to allow changing of levels. These 
are also against the latest CVS tree form SourceForge.

The new patches (and a diff between the original and latest) are here:

http://dgoeddel.home.insightbb.com/kern-0125.patch
http://dgoeddel.home.insightbb.com/usr-0125.patch
http://dgoeddel.home.insightbb.com/0117to0125.patch

Note that the mounting issue pointed out by Stephen is not addressed by this 
patch.  I figured that would best be addressed separately because it is not 
specific to these changes.

Thanks.

-- 

Darrel

--
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: [patch] enhanced MLS support

[Stephen Smalley]

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

On Tue, 2005-01-25 at 18:15, Darrel Goeddel wrote:
> I have new patches that incorporates feedback that I have received (and some 
> things that I noticed).  There is some code cleanup, and some bugfixes that 
> never made their way into the the MLS code before.  The most noticeable change 
> is the addition of the "-l" option to newrole to allow changing of levels. These 
> are also against the latest CVS tree form SourceForge.
> 
> The new patches (and a diff between the original and latest) are here:
> 
> http://dgoeddel.home.insightbb.com/kern-0125.patch
> http://dgoeddel.home.insightbb.com/usr-0125.patch
> http://dgoeddel.home.insightbb.com/0117to0125.patch
> 
> Note that the mounting issue pointed out by Stephen is not addressed by this 
> patch.  I figured that would best be addressed separately because it is not 
> specific to these changes.

Thanks.  Merged into sourceforge CVS.  I also applied the attached
policy Makefile patch relative to your patch as a compatibility measure;
it ensures that if you rebuild policy after updating to the new
checkpolicy, it will still build policy.18 as well (for older kernels)
and if you perform a make load and your kernel does not support the
latest policy version, it will fall back to policy.18.

Note to Dan:  You should likely wait on updating to the new libsepol
(1.3.1) and checkpolicy (1.21.1) from sourceforge CVS until we submit
the kernel changes upstream.  While they do have the usual compatibility
code for older policy binary versions, there is no advantage to updating
yet and further changes to the policy binary version may be coming.  But
feel free to continue updating from policycoreutils (newrole -l support)
and policy; that should have no impact on you.

Follow-up to my earlier note about getting a system up and running with
the enhanced MLS support:  In addition to the changes I described
earlier (and included in the patch I posted), I also had to make several
further changes for basic operation at multiple levels:
1) Set the clearance for the kernel SID to the max, i.e.
initial_sid_contexts contains:
	sid kernel system_u:system_r:kernel_t:s0 - s9:c0 . c127
2) Authorize system_u for the max, i.e. users contains:
	user system_u roles system_r level s0 range s0 - s9:c0 . c127;
3) Add mlsprocread, mlsprocwrite attributes to kernel_t (necessary for
the share permission check between kernel_t and init_t when init is
executed).
4) Add mlsfileread, mlsfilewrite, mlsfileupgrade, mlsfiledowngrade,
mlsprocsetsl attributes to newrole_t (necessary for newrole -l support
to work in enforcing mode).



-- 
Stephen Smalley <sds@tycho.nsa.gov>
National Security Agency

[-- Attachment #2: policy-Makefile.diff --]
[-- Type: text/x-patch, Size: 1594 bytes --]

Index: policy/Makefile
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/policy/Makefile,v
retrieving revision 1.64
retrieving revision 1.65
diff -u -r1.64 -r1.65
--- policy/Makefile	26 Jan 2005 19:22:00 -0000	1.64
+++ policy/Makefile	26 Jan 2005 19:46:00 -0000	1.65
@@ -22,7 +22,9 @@
 LOADPOLICY  = $(SBINDIR)/load_policy
 CHECKPOLICY = $(BINDIR)/checkpolicy
 SETFILES = $(SBINDIR)/setfiles
-POLICYVER := policy.$(shell $(CHECKPOLICY) $(POLICYCOMPAT) -V |cut -f 1 -d ' ')
+VERS := $(shell $(CHECKPOLICY) $(POLICYCOMPAT) -V |cut -f 1 -d ' ')
+KERNVERS := $(shell cat /selinux/policyvers)
+POLICYVER := policy.$(VERS)
 INSTALLDIR = $(DESTDIR)/etc/selinux/strict
 POLICYPATH = $(INSTALLDIR)/policy
 SRCPATH = $(INSTALLDIR)/src
@@ -127,6 +129,9 @@
 $(LOADPATH):  policy.conf $(CHECKPOLICY)
 	mkdir -p $(POLICYPATH)
 	$(CHECKPOLICY) $(CHECKPOLMLS) -o $@ policy.conf
+ifneq ($(VERS),18)
+	$(CHECKPOLICY) $(CHECKPOLMLS) -c 18 -o $(POLICYPATH)/policy.18 policy.conf
+endif
 # Note: Can't use install, so not sure how to deal with mode, user, and group
 #	other than by default.
 
@@ -134,11 +139,18 @@
 
 $(POLICYVER):  policy.conf $(FC) $(CHECKPOLICY)
 	$(CHECKPOLICY) $(CHECKPOLMLS) -o $@ policy.conf
+ifneq ($(VERS),18)
+	$(CHECKPOLICY) $(CHECKPOLMLS) -c 18 -o policy.18 policy.conf
+endif
 	@echo "Validating file_contexts ..."
 	$(SETFILES) -q -c $(POLICYVER) $(FC)
 
 reload tmp/load: install
+ifeq ($(VERS), $(KERNVERS))
 	$(LOADPOLICY) $(LOADPATH)
+else
+	$(LOADPOLICY) $(POLICYPATH)/policy.18
+endif
 	touch tmp/load
 
 load: tmp/load

Re: [patch] enhanced MLS support

[Stephen Smalley]

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

On Fri, 2005-01-21 at 13:04, Stephen Smalley wrote:
> This patch relative to your userland patch makes the additional changes
> needed to at least compile a MLS policy (based on the strict policy), as
> described in my prior email.

As you may have noticed, my policy patch for MLS was almost immediately
broken by the next merge of contributed policy patches, as any change to
the file contexts will naturally conflict with the addition of the MLS
level fields.  Hence, to allow easy generation of an initial MLS-enabled
policy from the latest policy tree, I've created a mlsconvert target in
the policy Makefile as shown in the below patch.  Hence, a 'make
mlsconvert' will perform substitutions on the policy context
configuration files, the file context configuration files, and the users
files to initially set them up to include MLS fields.  Naturally,
further work is required for a useful MLS system, e.g. assigning MLS
attributes to domains that require privilege.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

[-- Attachment #2: policy-Makefile-mls.diff --]
[-- Type: text/x-patch, Size: 4019 bytes --]

Index: policy/Makefile
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/policy/Makefile,v
retrieving revision 1.66
diff -u -r1.66 Makefile
--- policy/Makefile	27 Jan 2005 19:42:05 -0000	1.66
+++ policy/Makefile	1 Feb 2005 16:04:50 -0000
@@ -13,7 +13,7 @@
 #
 
 # Set to y if MLS is enabled in the policy.
-MLS=n
+MLS=y
 
 FLASKDIR = flask/
 PREFIX = /usr
@@ -25,7 +25,11 @@
 VERS := $(shell $(CHECKPOLICY) $(POLICYCOMPAT) -V |cut -f 1 -d ' ')
 KERNVERS := $(shell cat /selinux/policyvers)
 POLICYVER := policy.$(VERS)
+ifeq ($(MLS),y)
+INSTALLDIR = $(DESTDIR)/etc/selinux/mls
+else
 INSTALLDIR = $(DESTDIR)/etc/selinux/strict
+endif
 POLICYPATH = $(INSTALLDIR)/policy
 SRCPATH = $(INSTALLDIR)/src
 USERPATH = $(INSTALLDIR)/users
@@ -48,15 +52,19 @@
 endif
 POLICYFILES += $(ALL_TUNABLES) $(TE_RBAC_FILES)
 POLICYFILES += $(USER_FILES)
-POLICYFILES += constraints initial_sid_contexts fs_use genfs_contexts net_contexts
+POLICYFILES += constraints
+POLICYFILES += initial_sid_contexts fs_use genfs_contexts net_contexts
+CONTEXTFILES = initial_sid_contexts fs_use genfs_contexts net_contexts
 
 UNUSED_TE_FILES := $(wildcard domains/program/unused/*.te)
 
 FC = file_contexts/file_contexts
-FCFILES=tmp/program_used_flags.te file_contexts/types.fc $(patsubst domains/program/%.te,file_contexts/program/%.fc, $(wildcard domains/program/*.te)) file_contexts/distros.fc $(wildcard file_contexts/misc/*.fc)
+FCFILES=file_contexts/types.fc $(patsubst domains/program/%.te,file_contexts/program/%.fc, $(wildcard domains/program/*.te)) file_contexts/distros.fc $(wildcard file_contexts/misc/*.fc)
+CONTEXTFILES += $(FCFILES)
 
 APPDIR=$(CONTEXTPATH)
 APPFILES = $(addprefix $(APPDIR)/,default_contexts default_type initrc_context failsafe_context userhelper_context removable_context dbus_contexts customizable_types) $(CONTEXTPATH)/files/media
+CONTEXTFILES += $(wildcard appconfig/*_context*) appconfig/media
 
 ROOTFILES = $(addprefix $(APPDIR)/users/,root)
 
@@ -129,8 +137,10 @@
 $(LOADPATH):  policy.conf $(CHECKPOLICY)
 	mkdir -p $(POLICYPATH)
 	$(CHECKPOLICY) $(CHECKPOLMLS) -o $@ policy.conf
+ifneq ($(MLS),y)
 ifneq ($(VERS),18)
-	$(CHECKPOLICY) $(CHECKPOLMLS) -c 18 -o $(POLICYPATH)/policy.18 policy.conf
+	$(CHECKPOLICY) -c 18 -o $(POLICYPATH)/policy.18 policy.conf
+endif
 endif
 # Note: Can't use install, so not sure how to deal with mode, user, and group
 #	other than by default.
@@ -139,8 +149,10 @@
 
 $(POLICYVER):  policy.conf $(FC) $(CHECKPOLICY)
 	$(CHECKPOLICY) $(CHECKPOLMLS) -o $@ policy.conf
+ifneq ($(MLS),y)
 ifneq ($(VERS),18)
-	$(CHECKPOLICY) $(CHECKPOLMLS) -c 18 -o policy.18 policy.conf
+	$(CHECKPOLICY) -c 18 -o policy.18 policy.conf
+endif
 endif
 	@echo "Validating file_contexts ..."
 	$(SETFILES) -q -c $(POLICYVER) $(FC)
@@ -194,9 +206,9 @@
 	@mkdir -p $(CONTEXTPATH)/files
 	install -m 644 $(FC) $(FCPATH)
 
-$(FC): $(FCFILES) $(ALL_TUNABLES) domains/program domains/misc file_contexts/program file_contexts/misc users /etc/passwd
+$(FC): $(ALL_TUNABLES) tmp/program_used_flags.te $(FCFILES) domains/program domains/misc file_contexts/program file_contexts/misc users /etc/passwd
 	@echo "Building file_contexts ..."
-	@m4 $(M4PARAM) $(ALL_TUNABLES) $(FCFILES) > $@.tmp
+	@m4 $(M4PARAM) $(ALL_TUNABLES) tmp/program_used_flags.te $(FCFILES) > $@.tmp
 	@grep -v "^/root" $@.tmp > $@.root
 	@/usr/sbin/genhomedircon . $@.root  > $@
 	@grep "^/root" $@.tmp >> $@
@@ -296,3 +308,17 @@
 	done
 
 .PHONY: clean $(PHONIES)
+
+mlsconvert: 
+	@for file in $(CONTEXTFILES); do \
+		echo "Converting $$file"; \
+		sed -e 's/_t\b/_t:s0/g' $$file > $$file.new && \
+		mv $$file.new $$file; \
+	done
+	@for file in $(USER_FILES); do \
+		echo "Converting $$file"; \
+		sed -e 's/;/ level s0 range s0 - s9 : c0 . c127;/' $$file > $$file.new && \
+		mv $$file.new $$file; \
+	done
+	@sed -e '/sid kernel/s/s0/s0 - s9 : c0 . c127/' initial_sid_contexts > initial_sid_contexts.new && mv initial_sid_contexts.new initial_sid_contexts
+	@echo "Done"

You mentioned somewhere there is a step by step guide to getting the MLS policy installed on a machine?

[Daniel J Walsh]

Where can I get that?

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.

Reloading Policy?

[John Buwa]

Hello,

I have selinux on my fedora core 3 install. I need to reload the policy but
can not figure out how. I read all the faq's and such stating 'make load' in
the policy directory. However I do not have this directory by default nor
the source. This came installed with the distro. I have rebooted and still
the changes have not taken effect.

Thanks,
John


--
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: You mentioned somewhere there is a step by step guide to getting the MLS policy installed on a machine?

[Stephen Smalley]

On Tue, 2005-03-22 at 16:22 -0500, Daniel J Walsh wrote:
> Where can I get that?

selinux-doc/README.MLS (look for the section titled INSTALLATION)

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: Reloading Policy?

[Stephen Smalley]

On Wed, 2005-03-23 at 01:41 -0800, John Buwa wrote:
> I have selinux on my fedora core 3 install. I need to reload the policy but
> can not figure out how. I read all the faq's and such stating 'make load' in
> the policy directory. However I do not have this directory by default nor
> the source. This came installed with the distro. I have rebooted and still
> the changes have not taken effect.

You can load a new binary policy file using the load_policy command,
e.g.
	/usr/sbin/load_policy /etc/selinux/targeted/policy/policy.18

If you need to customize policy, you can modify the policy sources and
then build and load a new policy using 'make load' in the policy source
directory, e.g.
	cd /etc/selinux/targeted/src/policy
	make load

If your system doesn't have the policy sources installed (not installed
by default on Fedora), then you can grab the RPM from the CD and install
it with rpm or just use yum to get the latest one, e.g.
	yum install selinux-policy-targeted-sources

Naturally, you'll want to yum update as well to get all updates for FC3
since the release.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: You mentioned somewhere there is a step by step guide to getting the MLS policy installed on a machine?

[Daniel J Walsh]

Stephen Smalley wrote:

>On Tue, 2005-03-22 at 16:22 -0500, Daniel J Walsh wrote:
>  
>
>>Where can I get that?
>>    
>>
>
>selinux-doc/README.MLS (look for the section titled INSTALLATION)
>
>  
>
If I follow those instructions with the Current Rawhide kernel and the 
soon to be released selinux-policy-mls, can I get a SELinux/MLS machine
up and running or do I need addtional packages from TCS?

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: You mentioned somewhere there is a step by step guide to getting the MLS policy installed on a machine?

[Stephen Smalley]

On Wed, 2005-03-23 at 08:57 -0500, Daniel J Walsh wrote:
> If I follow those instructions with the Current Rawhide kernel and the 
> soon to be released selinux-policy-mls, can I get a SELinux/MLS machine
> up and running or do I need addtional packages from TCS?

You should be able to get a basic system working without any further
packages (I did).  But you will need to make the home directory and /tmp
ranged (as mentioned in README.MLS) in order to allow access by multiple
levels since the polyinstantiated directory support is not in the
mainline kernel, and are likely to encounter various denials when trying
to operate at multiple levels.  For a fully operational MLS system,
there will have to be further userspace work.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: You mentioned somewhere there is a step by step guide to getting the MLS policy installed on a machine?

[Paul Moore]

Stephen Smalley wrote:
> On Wed, 2005-03-23 at 08:57 -0500, Daniel J Walsh wrote:
> 
>>If I follow those instructions with the Current Rawhide kernel and the 
>>soon to be released selinux-policy-mls, can I get a SELinux/MLS machine
>>up and running or do I need addtional packages from TCS?
>  
> You should be able to get a basic system working without any further
> packages (I did).  But you will need to make the home directory and /tmp
> ranged (as mentioned in README.MLS) in order to allow access by multiple
> levels since the polyinstantiated directory support is not in the
> mainline kernel, and are likely to encounter various denials when trying
> to operate at multiple levels.  For a fully operational MLS system,
> there will have to be further userspace work.
> 

I just wanted to get some clarification here as the MLS README is a 
little vague in this area - assuming I have followed all of the install 
instructions in the README file, what we be the correct label to use for 
the mountpoints (one of the last steps in the install process), 
especially the pseudo filesystems such as /proc?

Thanks,

-- 
. paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. paul.moore@hp.com                                      hewlett packard
. (603) 884-5056                                          linux security

--
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: You mentioned somewhere there is a step by step guide to getting the MLS policy installed on a machine?

[Stephen Smalley]

On Thu, 2005-04-14 at 16:24 -0400, Paul Moore wrote:
> I just wanted to get some clarification here as the MLS README is a 
> little vague in this area - assuming I have followed all of the install 
> instructions in the README file, what we be the correct label to use for 
> the mountpoints (one of the last steps in the install process), 
> especially the pseudo filesystems such as /proc?

Good timing; I just got done converting a fresh FC4 test2 install over
to MLS, and James Morris has recently experimented with the MLS
conversion as well.  I'm making some minor updates to README.MLS based
on that experience.  chcon system_u:object_r:file_t:s0 /proc should work
for you.  A few other points to note:
1) I had to umount /proc/bus/usb and /proc/sys/fs/binfmt_misc prior to
being able to umount /proc.
2) I also had to umount and relabel /var/lib/nfs/rpc_pipefs.
3) Rather than immediately booting the MLS-enabled kernel into multi-
user mode, you should instead boot with enforcing=0 single to fix up the
context on /etc/mtab, which is re-created by the shutdown while you were
still running with selinux=0.  You can run /sbin/restorecon /etc/mtab
from single-user mode, then /usr/sbin/setenforce 1 and exit the single-
user shell to come up multi-user.

I did the conversion from strict policy.

-- 
Stephen Smalley <sds@tycho.nsa.gov>
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: You mentioned somewhere there is a step by step guide to getting the MLS policy installed on a machine?

[Luke Kenneth Casson Leighton]

On Thu, Apr 14, 2005 at 04:38:13PM -0400, Stephen Smalley wrote:

> 3) Rather than immediately booting the MLS-enabled kernel into multi-
> user mode, you should instead boot with enforcing=0 single to fix up the
> context on /etc/mtab, which is re-created by the shutdown while you were
> still running with selinux=0.  You can run /sbin/restorecon /etc/mtab
> from single-user mode, then /usr/sbin/setenforce 1 and exit the single-
> user shell to come up multi-user.

 /etc/mtab is/was an issue (not in MLS) iirc with debian - it
 was the cause of much grief - esp. when a program didn't exit
 at shutdown, locked the partition (e.g. /usr), caused umount
 to fail, cascade-caused /etc/mtab to not be updated, there's
 a bug in /etc/init.d/mountvirtfs.sh where it incorrectly
 detect(s/ed?) that /etc/mtab wasn't writeable, cascade-caused
 mountvirtfs.sh to think that /usr was still mounted read-write
 from the prior shutdown, and it went pear-shaped from there.

 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.

Re: You mentioned somewhere there is a step by step guide to getting the MLS policy installed on a machine?

[James Morris]

On Thu, 14 Apr 2005, Paul Moore wrote:

> I just wanted to get some clarification here as the MLS README is a 
> little vague in this area - assuming I have followed all of the install 
> instructions in the README file, what we be the correct label to use for 
> the mountpoints (one of the last steps in the install process), 
> especially the pseudo filesystems such as /proc?

In general you just add :s0 to the end of the existing context.

Use getfattr -n security.selinux to see what they are with selinux=0



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




--
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: [patch] enhanced MLS support

[Chad Hanson]

 
On Mon, 2005-01-24 at 11:38, Casey Schaufler wrote:

> You could certainly store handling caveats in
> the category bitmaps, but expressing NOFORN
> in categories has been tried and does not work.

I'm not sure of your exact desire, but categories can be used directly (not
sufficient for releasabilities) or grouped together for use by a higher
level language which can make more complex relationships.

-Chad
_______________________________________
Chad Hanson
Manager, Trusted Operating Systems Lab

Trusted Computer Solutions
121 W Goose Alley
Urbana, IL  61801

www.TrustedCS.com

V: 217.384.0028  ext.12
F: 217.384.0288
E: chanson@TrustedCS.com


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