MCS

Daniel J Walsh dwalsh at redhat.com
Wed Sep 7 12:39:22 UTC 2005


Stephen Smalley wrote:

>On Fri, 2005-09-02 at 10:40 -0400, Gene Czarcinski wrote: 
>  
>
>>While I am more interested in a MLS (Multiple Level System) capability with 
>>selinux, MCS is pretty close since it is "simply" MLS (multi-levels, 
>>multi-categories) with a single level and multi-categories.
>>    
>>
>
>I'll take a stab at answering, although I think that James or Dan will
>have more precise answers for MCS.
>
>MCS and MLS are actually rather different.  IIUC, under MCS, clearance
>determines current access rather than current level, and objects (files)
>are only labeled with categories upon explicit request by the process
>(e.g. the user runs chcon on the file to set a category on it).  MCS
>doesn't try to prevent "write down", so it doesn't try to address the
>trojan horse problem.  MCS is effectively a discretionary model to allow
>users to mark their data with additional tags that further restrict
>access.  The only mandatory aspect is authorizing users for categories
>by defining their clearance in policy.  However, MCS and MLS exercise
>the same code paths and share the same support infrastructure.  They
>just differ in their specific configuration.
>
>  
>
>>However, I do have some questions --
>>
>>1.  Is most/all of the needed updates available for FC4 or should I plan to 
>>use the FC5-development packages?
>>    
>>
>
>You'll need the development packages, and some of the MCS-related
>packages are still only in Dan's own site at present for experimentation
>AFAIK.  See his posting to selinux list.
>  
>
Yes that is correct.  libsetrans and targeted policy with mcs are on my 
people page, but everything else is in rawhide.

>  
>
>>2.  It appears that MCS is only available with targeted policy (not with the 
>>strict policy).  Are there plans to include it in strict at some future time?
>>    
>>
>
>MCS is based on targeted, as the goal IIUC is for it to replace targeted
>as the default policy in Fedora.  Porting MCS to strict likely wouldn't
>be hard.  Dan also posted links to a MLS (not MCS) policy based on
>strict available from his site earlier to selinux list.  Not clear if he
>is still maintaining that, although there will ultimately be a MLS
>policy separate from MCS.
>  
>
We will turn it on in strict policy, also by default.  Haven't yet 
because I have been trying to get it to work in
targeted.

>  
>
>>3.  To me, a key capability to make either MLS or MCS practical is to 
>>implement polyinstantiation of /tmp and /home/<userid> directories so that 
>>different levels and/or categories with really have different directories.  
>>Has this been implemented?  How does it work?
>>    
>>
>
>Under development - see Janak's postings to selinux and redhat-lspp
>lists.  It is being done in userspace via per-process namespaces and
>bind mounts.  Currently also depends on a kernel patch that isn't
>upstream yet for unshare(2). 
>
>  
>
>>4.  How do I enable MCS given that I am now running selinux-targeted in 
>>enforcing mode?
>>    
>>
>
>You need to update to rawhide, and then you can install the MCS packages
>from Dan's site, I believe. 
>
>  
>
Yes.  Although it is currently broken in that users/root are only 
logging in as "s0" not "s0:c0.c127" or "s0:c0,c2,c17"
 

>>Comment:  While I understand that Red Hat folks would want to make a system 
>>upgrade to MCS NOT require a system relabel,  I (personally) do not consider 
>>it a big deal to require full relabeling to transition to either MCS or MLS.
>>    
>>
>
>But it is critical if they want to make MCS the default in FC5, so that
>people can upgrade from FC4. 
>  
>
Yes we can not force a relabel. 

>  
>
>>5.  Is it the goal for MCS to make it fully implemented and an 
>>installation/upgrade option for FC5?
>>    
>>
>
>Fully implemented IIUC. 
>
>  
>
It will not be an option, it will be enabled in both targeted and strict 
policy.

>>6.  Any tips on using MCS?
>>
>>    
>>
Not yet, we are learning as we go.  One rule we have now is categories 
can not have spaces in the translation.

Things we are working on:
    Infrastructure to allow different users to login with different 
categories.
    If I want to allow a web site to show "CompanyConfidential" 
documents what do I need to do?
   

>>7.  Is there anything the developers would especially like tested?
>>    
>>
>
>I'll leave these to Dan or James.
>
>  
>
Just need people to play with it and figure out where it is broken.

>>8.  IIUC, "newrole -l" will be used to switch level & category on an MLS 
>>system and "just" category on an MCS system.  Is this correct?
>>    
>>
>
>I would expect so, although possibly newrole could take an option just
>for category setting.
>
>  
>
We do not intend for people to use newrole in MCS.

>>9.  IIUC, the implementation supports a large number of levels (currently 10 
>>or s0-s9 but could be larger or smaller) and an even larger number of 
>>categories (currently 128 or c0-c127 but could be larger or smaller).  Is 
>>this correct?
>>    
>>
>
>Yes.  No fundamental limitations there.
>
>  
>
>>10.  While the current implementation has levels specified as s0-s9 and 
>>categories as c0-c127, there needs to some way to relate these "internal" 
>>specifications to something more meaningful to real people.  For example, for 
>>sensitivity levels specifying s0=unclassified, s1=confidential, s2=secret, 
>>etc.  In a similar manner, categories need something like c0=foo, c1=bar, 
>>c2=CompanyPropin, etc.  Has anything been done with this in mind?  What are 
>>the plans for this?
>>    
>>
>
>Yes, libselinux will now invoke an external translation library for
>contexts if it is present on the system.   Currently available from
>Dan's site.
>
>  
>


-- 





More information about the fedora-selinux-list mailing list