From: Crispin Cowan <crispin@wirex.com>
To: Alexander Viro <viro@math.psu.edu>
Cc: Christoph Hellwig <hch@infradead.org>, Greg KH <greg@kroah.com>,
torvalds@transmeta.com, linux-kernel@vger.kernel.org,
linux-security-module@wirex.com
Subject: Re: [PATCH] remove sys_security
Date: Fri, 18 Oct 2002 02:02:19 -0700 [thread overview]
Message-ID: <3DAFCE1B.805@wirex.com> (raw)
In-Reply-To: Pine.GSO.4.21.0210180309540.18575-100000@weyl.math.psu.edu
[-- Attachment #1: Type: text/plain, Size: 3477 bytes --]
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
>side.
>
We took a system protected with SubDomain to Defcon and kicked ass
http://news.com.com/2100-1001-948404.html?tag=rn
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
interface.
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.
Crispin
[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]
next prev parent reply other threads:[~2002-10-18 8:56 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-17 18:50 [PATCH] remove sys_security Christoph Hellwig
2002-10-17 18:53 ` Greg KH
2002-10-17 18:58 ` Christoph Hellwig
2002-10-17 19:07 ` Greg KH
2002-10-17 20:04 ` Christoph Hellwig
2002-10-17 20:10 ` Greg KH
2002-10-17 20:12 ` Christoph Hellwig
2002-10-18 7:04 ` Crispin Cowan
2002-10-18 7:07 ` David S. Miller
2002-10-18 8:31 ` Crispin Cowan
2002-10-18 8:29 ` David S. Miller
2002-10-18 12:52 ` Christoph Hellwig
2002-10-18 15:04 ` Greg KH
2002-10-19 2:05 ` Crispin Cowan
2002-10-18 7:11 ` Greg KH
2002-10-18 7:28 ` Alexander Viro
2002-10-18 9:02 ` Crispin Cowan [this message]
2002-10-18 13:05 ` Christoph Hellwig
2002-10-18 15:14 ` Valdis.Kletnieks
2002-10-18 15:18 ` Christoph Hellwig
2002-10-18 16:30 ` Russell Coker
2002-10-18 16:33 ` Christoph Hellwig
2002-10-18 16:53 ` Greg KH
2002-10-18 16:54 ` Russell Coker
2002-10-18 17:15 ` Stephen Smalley
2002-10-18 22:36 ` Chris Wright
2002-10-21 13:54 ` Mike Wray
2002-10-21 14:09 ` Christoph Hellwig
2002-10-21 16:44 ` Mike Wray
2002-10-21 17:36 ` Christoph Hellwig
2002-10-18 20:36 ` David Wagner
2002-10-18 17:44 ` Stephen Smalley
2002-10-18 16:38 ` Russell Coker
2002-10-18 16:52 ` Richard B. Johnson
2002-10-18 9:09 ` David Wagner
2002-10-18 10:14 ` Russell Coker
2002-10-18 12:50 ` Christoph Hellwig
2002-10-17 20:30 ` Jeff Garzik
2002-10-17 21:00 ` Russell Coker
2002-10-17 21:10 ` Jeff Garzik
2002-10-17 21:37 ` Russell Coker
2002-10-17 21:49 ` Alexander Viro
2002-10-17 22:14 ` Russell Coker
2002-10-17 22:22 ` Andreas Dilger
2002-10-23 0:35 ` Stephen C. Tweedie
2002-10-23 11:43 ` Russell Coker
2002-10-23 11:59 ` Stephen C. Tweedie
2002-10-23 14:27 ` Stephen Smalley
2002-10-23 14:54 ` Stephen C. Tweedie
2002-10-23 16:09 ` Stephen Smalley
2002-10-23 16:24 ` Christoph Hellwig
2002-10-23 16:34 ` Stephen Smalley
2002-10-23 16:36 ` Christoph Hellwig
2002-10-23 16:51 ` Stephen Smalley
2002-10-24 6:26 ` Nathan Scott
2002-10-24 8:45 ` Russell Coker
2002-10-17 20:45 ` Russell Coker
2002-10-21 13:57 ` Alan Cox
2002-10-21 21:12 ` Crispin Cowan
2002-10-21 21:17 ` Greg KH
2002-10-22 12:22 ` Stephen Smalley
2002-10-17 20:20 ` Russell Coker
2002-10-17 20:27 ` Christoph Hellwig
2002-10-17 20:28 ` Greg KH
2002-10-17 19:05 ` Alexander Viro
2002-10-17 20:18 ` David S. Miller
2002-10-17 20:36 ` Greg KH
2002-10-17 20:38 ` David S. Miller
2002-10-17 20:58 ` Greg KH
2002-10-17 20:58 ` David S. Miller
2002-10-17 22:09 ` Greg KH
2002-10-17 22:07 ` David S. Miller
2002-10-17 22:19 ` Greg KH
2002-10-18 8:00 ` Crispin Cowan
2002-10-18 7:57 ` David S. Miller
2002-10-18 13:08 ` Christoph Hellwig
2002-10-17 21:54 ` David Wagner
2002-10-17 22:36 ` David S. Miller
2002-10-17 23:04 ` Chris Wright
2002-10-17 23:08 ` David S. Miller
2002-10-18 14:24 ` Jakob Oestergaard
2002-10-17 22:51 ` Andreas Steinmetz
2002-10-17 22:51 ` David S. Miller
2002-10-18 17:47 ` Daniel Egger
2002-10-17 23:00 ` Jeff Garzik
2002-10-17 22:56 ` David S. Miller
2002-10-17 23:09 ` Greg KH
2002-10-17 23:10 ` Chris Wright
2002-10-17 23:10 ` Andreas Steinmetz
2002-10-18 13:11 ` Christoph Hellwig
2002-10-17 23:11 ` Greg KH
[not found] <20021017201030.GA384@kroah.com.suse.lists.linux.kernel>
[not found] ` <20021017211223.A8095@infradead.org.suse.lists.linux.kernel>
[not found] ` <3DAFB260.5000206@wirex.com.suse.lists.linux.kernel>
[not found] ` <20021018.000738.05626464.davem@redhat.com.suse.lists.linux.kernel>
[not found] ` <3DAFC6E7.9000302@wirex.com.suse.lists.linux.kernel>
2002-10-18 9:25 ` Andi Kleen
2002-10-18 9:36 ` Crispin Cowan
2002-10-18 9:44 ` Andi Kleen
2002-10-18 9:55 ` Russell Coker
2002-10-18 10:13 ` Andi Kleen
2002-10-18 17:24 ` Rik van Riel
2002-10-18 11:43 ` Andreas Ferber
[not found] <20021023155457.L2732@redhat.com.suse.lists.linux.kernel>
[not found] ` <Pine.GSO.4.33.0210231112420.7042-100000@raven.suse.lists.linux.kernel>
2002-10-23 16:33 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3DAFCE1B.805@wirex.com \
--to=crispin@wirex.com \
--cc=greg@kroah.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@wirex.com \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox