linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Wright <chris@wirex.com>
To: Christoph Hellwig <hch@infradead.org>, Greg KH <greg@kroah.com>,
	linux-kernel@vger.kernel.org, linux-security-module@wirex.com
Subject: Re: [RFC] LSM changes for 2.5.38
Date: Mon, 30 Sep 2002 02:08:44 -0700	[thread overview]
Message-ID: <20020930020844.H12641@figure1.int.wirex.com> (raw)
In-Reply-To: <20020927003210.A2476@sgi.com>; from hch@infradead.org on Fri, Sep 27, 2002 at 12:32:10AM -0400

* Christoph Hellwig (hch@infradead.org) wrote:
> 
> >  	if (turn_on && !capable(CAP_SYS_RAWIO))
> >  		return -EPERM;
> > -
> > + 
> > + 	ret = security_ops->ioperm(from, num, turn_on);
> > + 	if (ret) {
> > + 		return ret;
> > + 	}
> > + 
> 
> Sorry, but this is bullshit (like most of the lsm changes).  Either you
> leave the capable in and say it's enough or you add your random hook
> and remove that one.

I agree, this is the way started, however it touches so much driver code
(not to mention core code) that it seemed likely to be rejected.  I'm
all for replacing capable() calls, but it's not a consistent interface
and can't always be simply exchanged.  I see no reason not to remove the
obvious ones right away.

> Just adding more and more hooks without thinking
> gets us exactly nowhere except to an unmaintainable codebase.

Your point is well-taken.  Of course, we do not want to produce
unmaintainable code.  The hook creation/placement has been thought about
and discussed quite a bit.  

> Also is there a _real_ need to pass in all the arguments?

It was placed there as an obvious contol point over which ioports
could be accessed.  We will definitely revisit this since it's not being
used.

> > + * @module_create:
> > + *	Check the permission before allocating space for a module.
> > + *	@name contains the module name.
> > + *	@size contains the module size.
> > + *	Return 0 if permission is granted.
> > + * @module_initialize:
> > + * 	Check permission before initializing a module.
> > + * 	@mod contains a pointer to the module being initialized.
> > + *	Return 0 if permission is granted.
> 
> Umm, you can't tell me you deny someone to initialize a module he has
> just created?

Coming from two separate system calls there is no guarantee the
callers will be in the same execution domain.

> > + * @sethostname:
> > + *	Check permission before the hostname is set to @hostname.
> > + *	@hostname contains the new hostname
> > + *	Return 0 if permission is granted.
> > + * @setdomainname:
> > + *	Check permission before the domainname is set to @domainname.
> > + *	@domainname contains the new domainname
> > + *	Return 0 if permission is granted.
> 
> You don't think this should maybe be just one hook?

sure, uts releated hooks could be collapsed.

> You might be allowed to swapon but not swapoff?

yes, again there is no assumption the execution domains would be the
same.

> > +static int cap_swapoff (struct swap_info_struct *swap)
> > +{
> > +	return 0;
> > +}
> 
> Live would be a lot simple if an unimplemented op would behave
> as returning zero..

Yes, I agree.  We've had a few patches that did this, nothing
committed to the LSM tree currently.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

  parent reply	other threads:[~2002-09-30  9:10 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-27  4:32 [RFC] LSM changes for 2.5.38 Christoph Hellwig
2002-09-26 22:51 ` Greg KH
2002-09-27 16:48   ` Christoph Hellwig
2002-09-27 16:55     ` Greg KH
2002-09-27 17:01       ` Christoph Hellwig
2002-09-27 17:24         ` Greg KH
2002-09-27 12:09 ` Stephen Smalley
2002-09-27 16:34   ` Greg KH
2002-09-27 16:55   ` Christoph Hellwig
2002-09-27 18:09     ` Valdis.Kletnieks
2002-09-27 18:19       ` Christoph Hellwig
2002-09-27 18:54         ` Valdis.Kletnieks
2002-09-27 18:59           ` Christoph Hellwig
2002-09-30 14:19             ` Valdis.Kletnieks
2002-09-30 14:51               ` Alan Cox
2002-10-01 16:55               ` Christoph Hellwig
2002-10-02 17:55                 ` Valdis.Kletnieks
2002-10-02 18:39                   ` Christoph Hellwig
2002-10-02 22:55                     ` Seth Arnold
2002-10-02 23:07                       ` Alan Cox
2002-09-27 19:00     ` Stephen Smalley
2002-10-01 17:06       ` Christoph Hellwig
2002-09-30  9:08 ` Chris Wright [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-09-26 20:25 Greg KH
2002-09-26 20:26 ` Greg KH
2002-09-26 20:27   ` Greg KH
2002-09-26 20:28     ` Greg KH
2002-09-26 20:28       ` Greg KH

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=20020930020844.H12641@figure1.int.wirex.com \
    --to=chris@wirex.com \
    --cc=greg@kroah.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@wirex.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;
as well as URLs for NNTP newsgroup(s).