>> Woah. Stop right there. You plan to _automatically_ set the immutable
>> bit when the sticky bit is set? If a copy or unpack an executable with
>> the sticky bit set, I won't be able to remove it? Oh crap!
>
> Sure, if you have CAP_SETFCAP, you should be able to remove both in a
> whack. Likewise, if you have write access to the file, writing should
> clear both. Since the kernel currently has _no_ policy for the sticky
> bit, I think implementing these shouldn't be a problem.
OK, this is somewhat tolerable for local filesystem use. Local solutions
are not enough though, and Richard Gooch's solution is starting to look
very good.
>>>> Imagine a Linux distribution that had this misfeature. It gets installed
>>>> on some new systems on the network. I sit down at my old Linux box,
>>>> make a nice executable, telnet to a new box, and do bad things. Yow!
>>>
>>> What the HECK are you talking about? You sit down at a Linux box that is
>>> exporting /usr to a new box? Then you edit the binaries on /usr (or
>>> create new ones) that do bad things on the new box?
>>
>> Forget /usr, anything will do. Consider /projects/trauma instead,
>> where local users are developing a game that needs CAP_SYS_RESOURCE.
>
> If the game is meant to be run by normal users, then you don't want a
> normal users' bash process to have CAP_SYS_RESOURCE in it's inheritable
> set; then _any_ process can inherit it. Rather, you want it in the
> permitted set. This means that your game developers will need the ability
> to mark a file 'setuid root' anyway, so they can set whatever they want in
> _either_ scheme.
The game developers need a way to get CAP_SYS_RESOURCE, which they are
authorized to use. The filesystem must be mounted in a way that enables
some kind of capability system. Access to a Linux 2.2 or Irix machine
should not give the game developers the CAP_CHOWN right.
One solution: the developers have a privileged tool that uses the
setuid-root hack to create an executable with CAP_SYS_RESOURCE.
> Now, I have a suggestion that should apply equally to either solution; it
> could be possible to specify in a mount option masks for permitted and
> inheritable. This would limit the actual capabilites the mount would
> honor. This could be nice for either implementation.
This is great. It can not be supported by Richard Gooch's system though.
I suppose one could scan the filesystem and then remount it.
>> It would be very bad to let a
>> user set or clear bits in either one.
>
> Right, but so far (according to my threads with Richard Gooch and Pavel
> Machek) any file that isn't setuid-root will still have it's inheritable
> bits honored.
Yes, with setuid the kernel pretends that the file has bits set.
Isn't this terribly gross?
> This would mean any file could inherit rights from the
> admin. With the sticky bit solution, a paranoid admin (or distribution
> maintainer) could configure the kernel to use default inheritable of 0,
> and only honor inheritable on a file that has been capability enabled.
> (which in this system is a priviledged operation). Yes, the distribution
> maintainer would have to set caps for _every_ file with a legitimate right
> to inherit caps, but I think it would be great to be able to do that. An
> admin would be virtually immune from trojan binaries on the local fs.
> ('sl -Fla' anyone? ;-)
No, this is not the correct solution. Trojan binaries can still mess
up the admin's home directory. Shell functions could be fun.
To solve the trojan problem, you need Mandatory Integrity. With that,
the admin can not access files or other data that might be contaminated.
Mandatory Access control is wild stuff. You can have multiple files with
the same name in the same directory. If you try to access a file that
you shouldn't access, the kernel will claim that the file does not
exist. (if you got "permission denied", you would know you guessed the
name of a forbidden file)
>> Here is a normal user process:
>>
>> CapInh: 00000000fffffeff
>> CapPrm: 0000000000000000
>> CapEff: 0000000000000000
>>
>> If you can freely set the inheritable bits on a file.
>>
>> pP' = fP | ( fI & pI )
>> pP' = fP | ( 00000000fffffeff & 00000000fffffeff )
>> pP' = fP | ( 00000000fffffeff )
>> pP' = at least 00000000fffffeff, which is almost everything
>>
>> The same goes for fP. They are about the same in fact, since you can't
>> safely remove bits from pI.
>
> I don't understand 'can't safely remove bits from pI.'...
Assume I am a normal user, and you let me drop some bits. I do that,
and then I run a setuid-root executable. This privileged process
tries to run some other executable, expecting that privileged operations
won't fail. Well, the operations do fail because the (fI & pI) result
does not produce all the bits that are needed.
>> I can see why the POSIX committee might
>> reject such a system, and perhaps we should respect their rejection.
>> The more I study this system (including kernel code) the worse it looks.
>
> I honestly don't know why it was rejected. I can only say that,
Well, the above is pretty bad. Users ought to be able to give up
their capabilities I think.
There is no way to make an exec() fail when it doesn't generate enough
bits to get the job done completely. You can force the bits, or you can
let the exec() proceed without enough capability.
The system is difficult to explain. The committee created confusion
by choosing matching names for both file and process bit sets. I think
they did this because it seemed easy to implement and had a symmetry
that looked beautiful at the time. The algorithm for determining what
happens is totally counter-intuitive. I think that very few people
will understand the system. Misunderstood security systems may be
worse than simple security, since admins are more likely to screw up.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/