linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Christoph Hellwig <hch@lst.de>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] disallow modular capabilities
Date: 3 Jan 2005 01:32:37 +0100
Date: Mon, 3 Jan 2005 01:32:37 +0100	[thread overview]
Message-ID: <20050103003237.GA89490@muc.de> (raw)
In-Reply-To: <20050103002102.GA5987@localhost>

On Sun, Jan 02, 2005 at 07:21:02PM -0500, David Meybohm wrote:
> > > the new security module that is being loaded has no idea what state all
> > > processes are in when the module gets loaded?
> > 
> > This can still be fine if you don't care about the security of 
> > everything that runs before (e.g. because it is controlled early
> > startup code). If you care about their security don't do it when
> > it hurts. 
> 
> But this also means every security module has to handle the case of
> being loaded after this time in the boot process interactively by
> administrators.  That's very complex and race-prone.

The administrator has to prevent the case or make sure
it doesn't cause any problems.

You just have to be careful to not start any daemons before it,
safest is probably to load it in the initrd.

> 
> > > What do you think about only allowing init to load LSM modules i.e.
> > > check in {mod,}register_security that current->pid == 1.
> > 
> > I think it's a bad idea. Such policy should be left to user space.
> 
> Well, by excluding some policy you have to put more code in the kernel
> in the LSM modules to handle being loaded at any time.  So, I don't

> think the dogma of "no policy in the kernel" is a good one to follow
> here:  it ignores the problem and creates new ones.

The kernel just assumes that root knows what he/she/it is doing.
Zillions of other kernel interfaces make the same assumptions.

-Andi

  reply	other threads:[~2005-01-03  0:32 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-02 20:00 [PATCH] disallow modular capabilities Christoph Hellwig
2005-01-02 20:01 ` Christoph Hellwig
2005-01-02 20:28 ` Andi Kleen
2005-01-02 20:30   ` Christoph Hellwig
2005-01-02 20:47     ` Andi Kleen
2005-01-02 22:36       ` David Meybohm
2005-01-02 23:30         ` Andi Kleen
2005-01-03  0:21           ` David Meybohm
2005-01-03  0:32             ` Andi Kleen [this message]
2005-01-03 14:38               ` Florian Weimer
2005-01-03 15:52               ` Alan Cox
2005-01-04 20:24 ` Lee Revell
2005-01-04 21:05   ` Linus Torvalds
2005-01-04 21:08     ` Christoph Hellwig
2005-01-04 21:31       ` Chris Wright
2005-01-04 21:09     ` Lee Revell

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=20050103003237.GA89490@muc.de \
    --to=ak@muc.de \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).