From: David Meybohm <dmeybohmlkml@bellsouth.net>
To: Andi Kleen <ak@muc.de>
Cc: Christoph Hellwig <hch@lst.de>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] disallow modular capabilities
Date: Sun, 2 Jan 2005 17:36:50 -0500 [thread overview]
Message-ID: <20050102223650.GA5818@localhost> (raw)
In-Reply-To: <m1is6fy2vm.fsf@muc.de>
On Sun, Jan 02, 2005 at 09:47:41PM +0100, Andi Kleen wrote:
> Christoph Hellwig <hch@lst.de> writes:
> >
> > At least Debian currently inserts the capabilities module on boot.
>
> That is fine as long as they control all code executed before
> that module loading. And if they do not it is their own fault
> and they have to fix that in user space or compile the capability in.
> Unix policy is to not stop root from doing stupid things because
> that would also stop him from doing clever things.
But if the module system creates security holes in the security system,
shouldn't that be avoided? Isn't this is a fundamental problem because
the new security module that is being loaded has no idea what state all
processes are in when the module gets loaded?
What do you think about only allowing init to load LSM modules i.e.
check in {mod,}register_security that current->pid == 1. Then init can
load the policy from some file in /etc changeable by the administrator
before starting any other processes. Then you don't have to recompile
the kernel to change policies, but you still need to reboot and can't
get into funky states.
Dave
next prev parent reply other threads:[~2005-01-02 22:43 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 [this message]
2005-01-02 23:30 ` Andi Kleen
2005-01-03 0:21 ` David Meybohm
2005-01-03 0:32 ` Andi Kleen
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=20050102223650.GA5818@localhost \
--to=dmeybohmlkml@bellsouth.net \
--cc=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