enhanced MLS support
Subsystems (2)
PATCH 1/1 enhanced MLS support
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.
Quoted 2 lines · Darrel Goeddel
Hello,
I have attached patches which provide many enhancements to the MLS...
Here is the userland patch.
Darrel
Quoted 5 lines · Darrel Goeddel
Quoted 2 lines · Darrel Goeddel
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.
Signature · 8 lines
Stephen Smalley <[email protected]> National Security Agency -- 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.
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.
Signature · 2 lines
Stephen Smalley <[email protected]> National Security Agency
Quoted 2 lines · Darrel Goeddel
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?
Quoted 2 lines
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
Signature · 9 lines
James Morris <[email protected]> -- 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 7 lines · --- James Morris
Quoted 1 line · Darrel Goeddel
Replaced the existing MLS logic with a flexible
system based on the current
Quoted 1 line
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.
Quoted 1 line
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
[email protected]
__________________________________________________
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 9 lines · Casey Schaufler
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.
Quoted 5 lines
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.
Signature · 8 lines
Stephen Smalley <[email protected]> National Security Agency -- 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 1 line · --- Stephen Smalley
TE is preferable for integrity protection.
Sorry, my acronym matcher failed on "TE".
Quoted 2 lines
IMHO, there is no need to
introduce a Biba model to SELinux.
It is probably more trouble than it's worth.
Quoted 7 lines
Quoted 5 lines
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
[email protected]
__________________________________
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 [email protected] with the words "unsubscribe selinux" without quotes as the message.
Quoted 1 line · Casey Schaufler
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.
Quoted 3 lines
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.
Signature · 8 lines
Stephen Smalley <[email protected]> National Security Agency -- 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.
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.
Signature · 6 lines
Darrel -- 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 8 lines · 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:
Quoted 7 lines
http://dgoeddel.home.insightbb.com/kern-0125.patch
http://dgoeddel.home.insightbb.com/usr-0125.patch
http://dgoeddel.home.insightbb.com/0117to0125.patchNote 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).
Signature · 2 lines
Stephen Smalley <[email protected]> National Security Agency
Index: policy/Makefile
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/policy/Makefile,v retrieving revision 1.64
retrieving revision 1.65
Makefile +13 -1
@@ -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
Quoted 3 lines · Stephen Smalley
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.
Signature · 2 lines
Stephen Smalley <[email protected]> National Security Agency
Index: policy/Makefile
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/policy/Makefile,v retrieving revision 1.66
Makefile +33 -7
@@ -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) > [email protected] + @m4 $(M4PARAM) $(ALL_TUNABLES) tmp/program_used_flags.te $(FCFILES) > [email protected] @grep -v "^/root" [email protected] > [email protected] @/usr/sbin/genhomedircon . [email protected] > $@ @grep "^/root" [email protected] >> $@
@@ -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?
In reply to Stephen SmalleyWhere can I get that?
Dan
Signature · 4 lines
-- 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.
Reloading Policy?
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 [email protected] 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?
In reply to Daniel J WalshQuoted 1 line · Daniel J Walsh
Where can I get that?
selinux-doc/README.MLS (look for the section titled INSTALLATION)
Signature · 8 lines
Stephen Smalley <[email protected]> National Security Agency -- 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.
Re: Reloading Policy?
In reply to John BuwaQuoted 5 lines · John Buwa
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.
Signature · 8 lines
Stephen Smalley <[email protected]> National Security Agency -- 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.
Re: You mentioned somewhere there is a step by step guide to getting the MLS policy installed on a machine?
In reply to Stephen SmalleyQuoted 11 lines · Stephen Smalley
Quoted 3 lines · Daniel J Walsh
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
Signature · 4 lines
-- 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.
Re: You mentioned somewhere there is a step by step guide to getting the MLS policy installed on a machine?
Quoted 3 lines · Daniel J Walsh
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.
Signature · 8 lines
Stephen Smalley <[email protected]> National Security Agency -- 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.
Re: You mentioned somewhere there is a step by step guide to getting the MLS policy installed on a machine?
Quoted 5 lines · Stephen Smalley
Quoted 2 lines · Daniel J Walsh
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?
Quoted 8 lines
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,
Signature · 8 lines
. paul moore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . [email protected] 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 [email protected] 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?
Quoted 5 lines · Paul Moore
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.
Signature · 8 lines
Stephen Smalley <[email protected]> National Security Agency -- 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.
Re: You mentioned somewhere there is a step by step guide to getting the MLS policy installed on a machine?
Quoted 6 lines · Stephen Smalley
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/mtabfrom single-user mode, then/usr/sbin/setenforce1 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 [email protected] 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?
In reply to Paul MooreQuoted 5 lines · Paul Moore
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
Signature · 10 lines
James Morris <[email protected]> -- 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.