[fmac-discuss] [RFC][PATCH] Basic security context transition support

[Glenn Faden]

Darren J Moffat wrote:
> Glenn Faden wrote:
>   
>> privileges with specific objects. Or we might have two switches for FMAC 
>> enabling: Restrictive(Off/Permissive/Enforcing) and 
>> Authoritative(Off,Tracing/Enforcing).
>>     
>
> I think I've followed all the discussion up to this point but I might be 
> missing some subtleties.
>
> I don't like the idea of integrating FMAC and having one or more 
> switches that amount to turning it off completely or changing how it 
> works in ways that the words above suggest.
>
> If we are going to have FMAC then I think it should always be there. 
> Just like we can't turn off privileges in Solaris 10 today, we dealt 
> with the backwards compatibility issues with setuid so that there is no 
> on/off switch for privileges and there isn't even an on/off switch for 
> privilege debugging like there was in previous Trusted Solaris releases 
> (instead a process flag and dtrace SDT probes).
>
> It might amount to the same thing but couldn't we instead have FMAC as 
> "Authoritative: Enforcing" but a default policy that preserves backwards 
> compatibility.  Similarly for Restrictive.
>
> Part of my concern is about is getting into a situation where a given 
> system deployment (based on best practices for the applications/services 
> being deployed) on a single kernel requires conflicting settings for the 
> Restrictive/Authoritative switches - if that is possible then I think 
> FMAC would be see as to complex by those doing the system deployment.
>   
I'm sympathetic to the argument that a feature should be on by default 
so that it gets well tested, but the restrictive aspects of FMAC will 
present a challenge if there is no way to disable it. In RHEL5 they ship 
with a relatively simple targeted policy which is on by default, so it 
gets well tested. We may be able to follow that model, but we need a way 
to recover and debug policies since they are much more complex than the 
current process rights management in Solaris, where we were able to 
preserve compatibility by interpreting setuid to root as all privileges. 
However, we disabled Trusted Extensions by default since we couldn't 
make the restrictions it imposed completely transparent.

On the other hand, the authoritative mode of FMAC could probably be 
enabled all the time, since it shouldn't cause backward compatibility 
issues.

--Glenn