public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Crispin Cowan <crispin@wirex.com>
To: "'Christoph Hellwig'" <hch@infradead.org>
Cc: magniett <Frederic.Magniette@lri.fr>,
	torvalds@transmeta.com, "Stephen D. Smalley" <sds@epoch.ncsc.mil>,
	greg@kroah.com, linux-security-module@wirex.com,
	linux-kernel@vger.kernel.org,
	"Makan Pourzandi (LMC)" <Makan.Pourzandi@ericsson.ca>
Subject: Re: What went wrong with LSM, was: Re: [BK PATCH] LSM changes for 2.5.59
Date: Wed, 12 Feb 2003 20:37:51 -0800	[thread overview]
Message-ID: <3E4B211F.8080501@wirex.com> (raw)
In-Reply-To: 20030212230550.A19831@infradead.org

[-- Attachment #1: Type: text/plain, Size: 2709 bytes --]

'Christoph Hellwig' wrote:

>On Wed, Feb 12, 2003 at 02:22:34PM -0800, Crispin Cowan wrote:
>
>>LSM does have an abstract design: it mediates 
>>access to major internal kernel objects (processes, inodes, etc.) by 
>>user-space processes, throwing access requests out to the LSM module.
>>    
>>
>We seem to use the term design differently.  And maybe my english
>wording wasn't perfect (I'm no native speaker..).  My objection is that
>LSM by itself does not enforce the tightest bit of security policy
>design.  Your "design" is putting in hooks before object accesses
>without making them tied to enforcing some security policy.
>
You're right, we're using English differently :-) I don't know what the 
above paragraph means. I can guess, but that's where the trouble is 
coming from. Based on the guessing:

    * Yes, LSM by itself does not enforce security policy.
    * Yes, the desing is to put hooks in front of important objects, and
      ask the modules if that access is ok.

The effect of this is to push security policy out to the modules. This 
is what Linus asked for, so that he would not have to maintain security 
policy or security policy engines.

>When reading this thread some people (e.g. David [*]) still seem that
>changes should be done for LSM's sake - but that's entirely wrong.
>The point of getting LSM or something similar in is for the sake
>of the _linux_ _kernel_ getting usefull features, not for enabling
>some small community writing out of tree modules.
>
You have often made this point about "for the Linux kernel's sake" vs. 
some other motivation, and it bothers me. It suggests that you somehow 
care about the Linux kernel more than I do. No, I care about the Linux 
kernel a lot. More over, I don't see how "who cares about the kernel 
more" is pertinent.

That aside, the Linux kernel per se is not some entity to be pleased 
like a stone god. Linux exists for its users. LSM is designed to benefit 
Linux kernel users. Some benefit by being able to add security features 
that they could not get before, because they are not capable of patching 
their own kernels. Some benefit by being able to produce experimental 
security modules without having to patch & track the Linux kernel. Some 
benefit by being able to unload security stuff and go for a leaner 
configuration.

LSM is not about pleasing a small number of module vendors. It is about 
benefiting a large number of potential users.

Crispin

-- 
Crispin Cowan, Ph.D.
Chief Scientist, WireX                      http://wirex.com/~crispin/
Security Hardened Linux Distribution:       http://immunix.org
Available for purchase: http://wirex.com/Products/Immunix/purchase.html
			    Just say ".Nyet"


[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

      parent reply	other threads:[~2003-02-13  4:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-12 16:58 [BK PATCH] LSM changes for 2.5.59 Makan Pourzandi (LMC)
2003-02-12 18:45 ` 'Christoph Hellwig'
2003-02-12 19:11 ` magniett
2003-02-12 18:38   ` 'Christoph Hellwig'
2003-02-12 22:22     ` Crispin Cowan
2003-02-12 23:05       ` What went wrong with LSM, was: " 'Christoph Hellwig'
2003-02-12 23:24         ` Jesse Pollard
2003-02-13  1:02         ` James Morris
2003-02-13  4:19           ` Crispin Cowan
     [not found]           ` <mailman.1045110181.1643.linux-kernel2news@redhat.com>
2003-02-13  5:12             ` Pete Zaitcev
2003-02-13  6:52               ` Crispin Cowan
2003-02-13  1:56         ` Casey Schaufler
2003-02-13  4:37         ` Crispin Cowan [this message]

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=3E4B211F.8080501@wirex.com \
    --to=crispin@wirex.com \
    --cc=Frederic.Magniette@lri.fr \
    --cc=Makan.Pourzandi@ericsson.ca \
    --cc=greg@kroah.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@wirex.com \
    --cc=sds@epoch.ncsc.mil \
    --cc=torvalds@transmeta.com \
    /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