LKML Archive on lore.kernel.org
 help / color / Atom feed
From: Stephen Smalley <sds@tycho.nsa.gov>
To: "Ahmed S. Darwish" <darwish.07@gmail.com>
Cc: James Morris <jmorris@namei.org>,
	Casey Schaufler <casey@schaufler-ca.com>,
	Adrian Bunk <bunk@kernel.org>, Chris Wright <chrisw@sous-sol.org>,
	Eric Paris <eparis@parisplace.org>,
	Alexey Dobriyan <adobriyan@sw.ru>,
	LKML <linux-kernel@vger.kernel.org>,
	LSM-ML <linux-security-module@vger.kernel.org>,
	Anrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH -v3 -mm] LSM: Add security= boot parameter
Date: Mon, 03 Mar 2008 10:54:02 -0500
Message-ID: <1204559642.23738.63.camel@moss-spartans.epoch.ncsc.mil> (raw)
In-Reply-To: <20080303153510.GA6963@ubuntu>


On Mon, 2008-03-03 at 17:35 +0200, Ahmed S. Darwish wrote:
> Hi James,
> 
> On Mon, Mar 03, 2008 at 07:29:22PM +1100, James Morris wrote:
> > On Sun, 2 Mar 2008, Ahmed S. Darwish wrote:
> > 
> > > Add the security= boot parameter. This is done to avoid LSM 
> > > registration clashes in case of more than one bult-in module.
> > > 
> > > User can choose a security module to enable at boot. If no 
> > > security= boot parameter is specified, only the first LSM 
> > > asking for registration will be loaded. An invalid security 
> > > module name will be treated as if no module has been chosen.
> > > 
> > > LSM modules must check now if they are allowed to register
> > > by calling security_module_enable(ops) first. Modify SELinux 
> > > and SMACK to do so.
> > 
> > I think this can be simplified by folding the logic into 
> > register_security(), rather than having a two-stage LSM registration 
> > process.
> > 
> > So, this function would now look like
> > 
> > 	int register_security(ops, *status);
> > 
> > and set *status to LSM_WAS_CHOSEN (or similar) if the module being 
> > registered was also chosen via the security= parameter.  If there is no 
> > value for the parameter, the first module to register is automatically 
> > chosen, to preserve existing behavior.
> > 
> > The calling code can then decide what to do, e.g. not panic if 
> > registration failed and the LSM was not chosen; panic on failure when it 
> > was chosen.
> > 
> 
> I liked to do it like that at first, but I faced two problems:
> 
> SElinux (As you already know ;)) does the security setup of the initial 
> task before calling register_security. Would it be safe to do this
> setup after registeration ?

I wouldn't recommend it - the hook functions presume that the initial
task security blob has been set up already, and that other dependencies
like the inode security cache and access vector cache have been created
and can be used.  We have to assume that the security hooks can start
being invoked as soon as we call register_security(), even if in
practice it won't happen until after the init function completes.

> Same case occurs for Smack, it does some locking initializations and
> setup initial task's security before registration.
> 
> Personally, I feel that it's nicer to let the LSM know if it's
> OK to initialize itself before hitting _the point of no return_ (registration).
> 
> Anyway, I have no problem to implement it using *status if my 
> concerns are wrong.
> 
> > > +static atomic_t security_ops_enabled = ATOMIC_INIT(-1);
> > 
> > I'd suggest getting rid of this atomic and using a spinlock to protect the 
> > global chosen_lsm string, which is always filled when an LSM registers.
> > 
> > >  
> > > +/* Save user chosen LSM */
> > > +static int __init choose_lsm(char *str)
> > > +{
> > > +	strncpy(chosen_lsm, str, SECURITY_NAME_MAX);
> > > +	chosen_lsm[SECURITY_NAME_MAX] = NULL;
> > 
> > You should never need to set the last byte to NULL -- it's initialized to 
> > that and by definition should never be overwritten.
> > 
> > > +int security_module_enable(struct security_operations *ops)
> > > +{
> > > +	if (!ops || !ops->name)
> > > +		return 0;
> > 
> > Lack of ops->name during registration needs to be a BUG_ON.
> > 
> 
> You'll find above three points fixed the next send. Thank you.
> 
> Regards,
> 
-- 
Stephen Smalley
National Security Agency


  reply index

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-01 19:07 [RFC PATCH -mm] LSM: Add lsm= " Ahmed S. Darwish
2008-03-01 20:28 ` Casey Schaufler
2008-03-01 21:11   ` Adrian Bunk
2008-03-01 21:29     ` Casey Schaufler
2008-03-01 23:27       ` [PATCH -v2 -mm] LSM: Add security= " Ahmed S. Darwish
2008-03-02  3:41         ` Casey Schaufler
2008-03-02  7:55           ` Ahmed S. Darwish
2008-03-02  7:49         ` Ahmed S. Darwish
2008-03-02 10:59           ` [PATCH -v3 " Ahmed S. Darwish
2008-03-02 18:37             ` Casey Schaufler
2008-03-03  8:29             ` James Morris
2008-03-03 15:35               ` Ahmed S. Darwish
2008-03-03 15:54                 ` Stephen Smalley [this message]
2008-03-03 21:24                   ` [PATCH -v4 " Ahmed S. Darwish
2008-03-03 22:16                     ` James Morris
2008-03-04  3:04                       ` [PATCH -v5 " Ahmed S. Darwish
2008-03-04  4:07                         ` James Morris
2008-03-05 22:29                         ` Andrew Morton
2008-03-05 22:56                           ` Ahmed S. Darwish
2008-03-05 23:06                             ` Ahmed S. Darwish
2008-03-05 22:56                           ` James Morris

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=1204559642.23738.63.camel@moss-spartans.epoch.ncsc.mil \
    --to=sds@tycho.nsa.gov \
    --cc=adobriyan@sw.ru \
    --cc=akpm@linux-foundation.org \
    --cc=bunk@kernel.org \
    --cc=casey@schaufler-ca.com \
    --cc=chrisw@sous-sol.org \
    --cc=darwish.07@gmail.com \
    --cc=eparis@parisplace.org \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@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

LKML Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lkml.kernel.org/lkml/0 lkml/git/0.git
	git clone --mirror https://lkml.kernel.org/lkml/1 lkml/git/1.git
	git clone --mirror https://lkml.kernel.org/lkml/2 lkml/git/2.git
	git clone --mirror https://lkml.kernel.org/lkml/3 lkml/git/3.git
	git clone --mirror https://lkml.kernel.org/lkml/4 lkml/git/4.git
	git clone --mirror https://lkml.kernel.org/lkml/5 lkml/git/5.git
	git clone --mirror https://lkml.kernel.org/lkml/6 lkml/git/6.git
	git clone --mirror https://lkml.kernel.org/lkml/7 lkml/git/7.git
	git clone --mirror https://lkml.kernel.org/lkml/8 lkml/git/8.git
	git clone --mirror https://lkml.kernel.org/lkml/9 lkml/git/9.git
	git clone --mirror https://lkml.kernel.org/lkml/10 lkml/git/10.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 lkml lkml/ https://lkml.kernel.org/lkml \
		linux-kernel@vger.kernel.org
	public-inbox-index lkml

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git