[lkml]   [2002]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] remove sys_security
Alexander Viro wrote:

>On Fri, 18 Oct 2002, Crispin Cowan wrote:
>> * server users can choose a highly secure model
>> * workstation users can choose something desktop oriented
>> * embedded people can choose nothing at all, or the specific
>> narrow-cast model that they need
>>On the other hand: what is the big cost here? One system call. Isn't
>>that actually *lower* overhead than the (say) half dozen
>>security-oriented syscalls we might convince you to accept if we drop
>>the sys_security syscall as you suggest? Why the fierce desire to remove
>>something so cheap?
>Because ugliness has its price. As for "highly secure"... Could we please
>see some proof? Clearly stated properties with code audit to verify them
>would be nice.
LSM being an interface, it doesn't provide that. LSM's objective is to
provide modules with the ability to mediate access to major internal
kernel objects by user processes.

The security modules, in turn, use this ability to mediate to access to
objects to implement some specific stated security property, and you
would have to audit the module's code.

Some simple properties in the OWLSM module (porting some of the
properties from the Openwall patch, and adding some more):

* root may not follow non-root symlinks in certain circumstances
(prevent some temp file attacks)
* non-root may not create a hard-link to root-owned files in certain
circumstances (prevent some other temp file attacks)
* may not ptrace root processes (preventing further recurrance of
the bugs in ptrace over the last year or so)

These policies help a lot to secure a system. But these policies also
break some things, so it is good that they be a loadable module, and not
a proposed Linux patch.

>I'm yet to see a single shred of evidence that so-called security improvements
>actually do improve security (as opposed to feeling of security - quite
>a different animal). And in this case burden of proof is clearly on your
We took a system protected with SubDomain to Defcon and kicked ass

That was a 2.2 version of SubDomain. SubDomain is in the process of
being ported to the 2.4 back-patch version of LSM.

>What I _do_ see is a lucrative market for peddlers of feel-good "solutions"
>that do not make anything secure but have miles-long feature lists that
>can be used to impress PHBs. Now, I have no particular problems with
>people who help suckers part with their money, but I don't see any reason
>to support them.
>3 or 4 patches that might be interesting would be better off without LSM.
>The rest... care to give a hard evidence that it is worth any support?
The SELinux and DTE modules provide a similar form of security, but with
different trade-offs between expressivenes and complexity. *Not* forcing
a specific choice in this space on users was a major reason Linus
rejected SELinux as a patch, and instead suggested enhancing the module

There is GOBS of evidence that mandatory access control enhances
security. But there is also gobs of evidence that mandatory access
control is a huge pain in the ass to manage, leading to a huge plethora
of different access control models. Being able to choose your model to
suit your needs & circumstances, or choose none at all, was another
reason for implementing an interface instead of a specific set of features.


[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2005-03-22 13:30    [W:0.088 / U:25.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site