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
next prev 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).