On Wed, Oct 02, 2002 at 01:55:14PM -0400, Valdis.Kletnieks@vt.edu 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:35 EST