linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Christoph Hellwig <hch@infradead.org>,
	linux-kernel@vger.kernel.org, linux-security-module@wirex.com
Subject: Re: [RFC] LSM changes for 2.5.38
Date: Thu, 26 Sep 2002 15:51:48 -0700	[thread overview]
Message-ID: <20020926225147.GC7304@kroah.com> (raw)
In-Reply-To: <20020927003210.A2476@sgi.com>

On Fri, Sep 27, 2002 at 12:32:10AM -0400, Christoph Hellwig wrote:
> 
> >  /* Set EXTENT bits starting at BASE in BITMAP to value TURN_ON. */
> >  static void set_bitmap(unsigned long *bitmap, short base, short extent, int new_value)
> > @@ -62,7 +63,12 @@
> >  		return -EINVAL;
> >  	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.  Just adding more and more hooks without thinking
> gets us exactly nowhere except to an unmaintainable codebase.

capable is needed to be checked, as we are not modifying the existing
permission logic.

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

I'll let Stephen answer that one, as SELinux uses it.

Oops, ok, nevermind, I don't see _any_ security module using this hook.
In fact they are using the capable(CAP_SYS_RAWIO) hook, which is exactly
what you suggest :)

I'll go remove it.

> >  			return -EPERM;
> >  	}
> > +	retval = security_ops->iopl(old, level);
> > +	if (retval) {
> > +		return retval;
> > +	}
> > +
> 
> again (and another few times)

Ok, again, no one is using it.  I'll go remove it (and go audit all of
the other hooks.)

> > + * @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?

Bah, ok, again no one uses these either.

Consider me roasted, I'll go audit this whole thing to try to justify
every one of the hooks we ask for.

Very sorry for bothering people.

thanks,

greg k-h

  reply	other threads:[~2002-09-26 22:48 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 [this message]
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
  -- 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=20020926225147.GC7304@kroah.com \
    --to=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).