On Fri, 27 Sep 2002 19:19:43 BST, Christoph Hellwig said:

> So I have to download the driver source and change the parameter
> to i_m_to_fscking_intelligent_for_the_nsa_eth=0?

By the same token, at that point you can download the kernel source and
build it without LSM. What I showed was a way to bypass the iptables
rules set up *WITHOUT REPLACING A MODULE* (which might be detected by
tripwire, or totally refused because the LSM rejects any writes in /lib/modules).

--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech

Attachments:

(No filename) (226.00 B)

2002-09-27 18:55:45

by Stephen Smalley

[permalink] [raw]

Subject: Re: [RFC] LSM changes for 2.5.38

On Fri, 27 Sep 2002, Christoph Hellwig wrote:

> In 2.5 LSM hooks are part of the Linux access checks, and any reason to
> make your patch less intrusive inb 2.4 doesn't apply anymore. Having
> two checks for the same thing is indeed very bad in will cause harm
> and maintaince burden in the long term. Don't do it.

So you want to move the 'if (turn_on && !capable(CAP_SYS_RAWIO)) return
-EPERM;' from the base kernel into the security module's ioperm() hook
function, in addition to whatever additional logic the module may
implement? [Assuming for the moment that we kept the ioperm() hook, even
though that isn't likely given its current lack of use and
architecture-specific nature].

If so, what about the rest of the kernel access checking logic? Do you
want all of the permission() logic pushed into the security module's
inode_permission() hook function? Do you want the bad_signal() logic
pushed into the security module's task_kill() hook function? That kind of
change was considered and discussed on linux-security-module long ago, but
it will yield a very invasive patch for very little gain. It also
requires cleanly separating all access checking logic from functional
logic (it is sometimes fairly intertwined) and determining exactly which
is which (e.g. is enforcing a read-only mount a security behavior or a
functional behavior?).

> Show me a useful example that needs this argument.

Do you want every process that can use ioperm() to be able to access the
full range of ports accessible by that call? If not, then you need
something finer-grained than CAP_SYS_RAWIO. But as I said, we don't
presently use this hook, and it is architecture-dependent.

> And WTF is the use a security policy that checks module arguments? Do
> you want to disallow options that are quotes from books on the index
> or not political correct enough for a US state agency?

The LSM module_initialize hook is called with a pointer to the kernel's
copy of the relocated module image with the struct module header. Hence,
the security module is free to perform whatever validation it wants on
that image prior to the execution of the init function. But if the
criteria is that there must be a specific existing security module that
uses the hook, then this one will go away too.

--
Stephen D. Smalley, NAI Labs
[email protected]

2002-09-27 18:54:02

by Christoph Hellwig

[permalink] [raw]

Subject: Re: [RFC] LSM changes for 2.5.38

On Fri, Sep 27, 2002 at 02:54:25PM -0400, [email protected] wrote:
> By the same token, at that point you can download the kernel source and
> build it without LSM. What I showed was a way to bypass the iptables
> rules set up *WITHOUT REPLACING A MODULE* (which might be detected by
> tripwire, or totally refused because the LSM rejects any writes in /lib/modules).

insmod doesn't require modules to be in /lib/modules. Anyway I could even change
the device name _after_ it was loaded. this is linux and not BSD..

Given that we really want to fine-grained control who's netdevice can get what
names we'd` better place a hook in dev_alloc_name.

And that's my whole point: LSM adds random hooks all over the place without
even thinking what they intend to protect.

2002-09-30 09:10:42

by Chris Wright

[permalink] [raw]

Subject: Re: [RFC] LSM changes for 2.5.38

* Christoph Hellwig ([email protected]) 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

2002-09-30 14:16:09

On Tue, 01 Oct 2002 17:55:00 BST, Christoph Hellwig said:

> For gods sake, what interface do you want to /bin/mv? network device don't have
> associated special files in Linux (or BSD). I'm talking about SIOCSIFNAME.

Well, I figured that you must have meant something else, since ioctl() is
hooked, so an attacker couldn't use THAT method if the security module didn't
want him to.

Of course, that means we probably should pull that ioctl() hook too, since
obviously there's ways to bypass it. And at that point, we may as well
pull the OTHER hooks too. Hmm.. I'm starting to see a pattern here. ;)

So we shouldn't deploy a check on module parameters to prevent renaming
an interface, and we shouldn't bother having OTHER checks to stop it
because they could always load a module and bypass it - if you feel THAT
strongly that the whole concept of a security framework is that pointless,
you're free not to use it. ;)

> How does the lsm author know what the option x=y means for my module? In my

Umm.. the same way that *I* noticed that 'eth=0' has a security implication.

It seems to me that you're arguing both sides here - first you say that
a full code audit is needed so you know 'WTF is going on', and then you're
saying that it's impossible to know.

Either that, or you're saying "yes you can do a code audit, but having identified
module parameters that are *KNOWN* to be a problem, you're not allowed to stop
them".

> From my reading of the LSM lists a hgook usually got added because author A
> of the unaudited module B though that it might help him in imlpementing what
> he and only he thinks his module should do if it worked properly.

OK - so to summarize: You're saying that somebody conceives of a reasonable
security model, finds a set of 10 or 15 hooks that implement 95% of what
he needs, but there's a code path that a hook doesn't catch that lets a user
subvert the model - and then it's a *BAD THING* that the kernel be modified
to *actually solve a problem*?

Somehow, this goes against the whole spirit of the Linux kernel - I wonder
what miniscule percent of the current kernel wasn't done to solve a problem...
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech

Attachments:

(No filename) (226.00 B)

2002-10-02 18:34:14

by Christoph Hellwig

[permalink] [raw]

Subject: Re: [RFC] LSM changes for 2.5.38

On Wed, Oct 02, 2002 at 01:55:14PM -0400, [email protected] wrote:
> On Tue, 01 Oct 2002 17:55:00 BST, Christoph Hellwig said:
>
> > For gods sake, what interface do you want to /bin/mv? network device don't have
> > associated special files in Linux (or BSD). I'm talking about SIOCSIFNAME.
>
> Well, I figured that you must have meant something else, since ioctl() is
> hooked, so an attacker couldn't use THAT method if the security module didn't
> want him to.

Just that no 'security' module implements a special handler for it. E.g. in
selinux it ends up in

/* default case assumes that the command will go
* to the file's ioctl() function.
*/
default:
error = file_has_perm(current, file, FILE__IOCTL);

> Of course, that means we probably should pull that ioctl() hook too, since
> obviously there's ways to bypass it.

Right. an hook for ->ioctl() is completly useless. Remember that ioctl
is nothing but a magic backdoor to add syscalls. You need to do the
permission check in code that actually knows what it is doing, not in
the dispatcher.

> So we shouldn't deploy a check on module parameters to prevent renaming
> an interface, and we shouldn't bother having OTHER checks to stop it
> because they could always load a module and bypass it

You should add a check where the name isactually assigned in this case.
Not that I think a check on the device name is generally a good idea..

> - if you feel THAT
> strongly that the whole concept of a security framework is that pointless,
> you're free not to use it. ;)

You've missed the point. I never wanted to use it. I care about the crap
that it adds to the kernel which I do want to use, develop and keep
clean.

> > How does the lsm author know what the option x=y means for my module? In my
>
> Umm.. the same way that *I* noticed that 'eth=0' has a security implication.

Without ever seeing that module?

> It seems to me that you're arguing both sides here - first you say that
> a full code audit is needed so you know 'WTF is going on', and then you're
> saying that it's impossible to know.

The person who performs the audit can know it. But how often will that be
the author of the LSM module?

> OK - so to summarize: You're saying that somebody conceives of a reasonable
> security model, finds a set of 10 or 15 hooks that implement 95% of what
> he needs, but there's a code path that a hook doesn't catch that lets a user
> subvert the model - and then it's a *BAD THING* that the kernel be modified
> to *actually solve a problem*?

It's not bad to solve a problem. It's a bad idea trying to 'solve' a problem
you don';t understand fully.

> Somehow, this goes against the whole spirit of the Linux kernel - I wonder
> what miniscule percent of the current kernel wasn't done to solve a problem...

Adding random hack without resolving the underlying problem is not the
way linux kernel development usually works.

2002-10-02 22:50:21

by Seth Arnold

[permalink] [raw]

Subject: Re: [RFC] LSM changes for 2.5.38

On Wed, Oct 02, 2002 at 07:39:40PM +0100, Christoph Hellwig wrote:
> > It seems to me that you're arguing both sides here - first you say that
> > a full code audit is needed so you know 'WTF is going on', and then you're
> > saying that it's impossible to know.
>
> The person who performs the audit can know it. But how often will that be
> the author of the LSM module?

We've said on this list a few times that it is important for security
module authors to understand the implications of their decisions.
Deciding to not mediate module parameters is a valid decision. Deciding
to mediate module parameters is a valid decision. One requires very
little thought and sidesteps the matter entirely. The other requires
quite a bit of thought and is difficult to get right -- but that is not
a problem for LSM, per se; it is for the authors of security modules.

--
http://immunix.org/

Attachments:

(No filename) (890.00 B)
(No filename) (240.00 B)
Download all attachments

2002-10-02 22:55:18

by Alan

[permalink] [raw]

Subject: Re: [RFC] LSM changes for 2.5.38

On Wed, 2002-10-02 at 23:55, Seth Arnold wrote:
> We've said on this list a few times that it is important for security
> module authors to understand the implications of their decisions.
> Deciding to not mediate module parameters is a valid decision. Deciding
> to mediate module parameters is a valid decision. One requires very
> little thought and sidesteps the matter entirely. The other requires
> quite a bit of thought and is difficult to get right -- but that is not
> a problem for LSM, per se; it is for the authors of security modules.

In many cases I disagree. Garbage in - garbage out. That goes for
security policy decisions as well as the revenue. The security modules
must get data that is sufficient to make the decision, locked correctly
and with a defined scope and lifespan.

For example passing an ascii path without thought is useless because you
would race name lookups against things like symlinks. The same goes for
audit stuff which is one of the reasons snare needs a lot of work yet

Alan