[Security_sig] 10/14 Conf. call minutes

[Stephen Smalley]

On Tue, 2004-10-19 at 13:26, Gé Weijers wrote:
> As I am one of the people who have expressed that sentiment I feel the 
> need to explain myself :-)

Thanks for taking the time to explain.

> As is stands right now SELinux is far removed from something I would 
> want to deploy in the field. There are a couple of reasons, which in the 
> end all boil down to one thing: complexity, and the resulting high cost 
> of ownership. It requires highly skilled people to correctly configure 
> SELinux, and it is exceedingly difficult to 'prove' that the 
> configuration actually meets your goals and policies. In the current 
> marketplace we need to improve security and lower cost of deployment at 
> the same time, and hiring $200/hour consultants does not help us to 
> achieve that goal.

Simpler solutions won't ultimately help with the threat.  As I've said
previously, SELinux didn't create the complexity; SELinux just reveals
what is truly happening and makes it possible to control.  And the complexity
of the policy is up to you; consider the targeted policy in Fedora as
an example of a much simpler policy.  You get to choose how granular
to make your policy.

Definitely agree that we need much better tools to manage and analyze that
complexity, but if people won't work toward that end, we'll never get
there.  And there are people who are working in this space, but
additional resources would help move things along faster.

> What would it require to change this? A couple of things:
> 
>     * policies need to be expressed in a way that "mere mortals" such as
>       busy sysadmins can understand.
>     * baseline policies should ideally come with the software you're
>       installing, and should be easy to modify to meet local requirements.
>     * policy violations should be reported in terms of the high level
>       policy specification, not in terms of lower-level abstractions.

Agree that all of these are desirable.

> None of the above is impossible, but it needs to be done. Given the 
> deafening silence we usually get when we ask security-related questions 
> I doubt that people will be standing in line to work on this. I wish it 
> were different.

Standing in line?   No.  But I believe that there are people in this
group who could apply more resources to these problems, and AFAIK, they
aren't doing so.

> Businesses need 'good enough' security at a low enough cost. As it 
> stands the cost of deploying SELinux outweighs the risk in many cases..

Based on what data?  Speculative.

> <soapbox>
> As an aside: another thing that worries me is code complexity (this is 
> not limited to SELinux, but extends to all of Linux, and *BSD, Solaris, 
> .....). The linux-2.6.8.1/security/selinux tree contains almost 16000 
> lines of code. The Biba module in FreeBSD 5.2.1 contains about 2900. The 
> latter is much easier to read and verify, and because it implements the 
> security model directly the error messages directly relate to the 
> security model. Complexity is our enemy.
> </soapbox>

Inadequate security models are of little help, no matter how simple and
easy to analyze.  And much of the simplicity is achieved by pushing
large chunks of functionality into the great unknown of "trusted
subject", able to completely override the security model.
Trent Jaeger's work at IBM Watson to analyze SELinux TE policy against
Biba constraints is more promising here, as you get to evaluate higher
level goals, clearly identify exception cases that occur in the real
world, and confine those exception cases as much as possible.
In any event, I think your concerns about policy complexity are more
legitimate than your concerns about code complexity here.

> This is exactly the right forum as far as I am concerned. Thanks for 
> jumping in.

Thanks for your response.

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