>> I'm not. I'm adding possibility for executable to drop some of its
>> privileges. This is obviously safe. Loosing priviledges should be safe
>> modulo broken programs which do not do proper error handling.
>
> It's certainly true that this is safe; I just get frustrated when people
> claim this has anything near the power of the full POSIX capabilities
> model.
"near" is subject to personal interpretation.
> However, an obvious question to ask at this point is why do it by
> hacking the ELF header? It's probably much simpler to have the
> executable explicitly drop capabilities by making an appropriate system
> call in the executable itself. This has the advantage that the kernel
...
> If people are looking for a short term hack, this is it. It doesn't
> require making any changes to the kernel, or any changes to any
> user-land administrative tools, nor do we need to teach administrators
> how to set these magic bits in the ELF headers. All we have to do is
> add the code into the daemons themselves. It doesn't give you the power
> of the full POSIX capabilities model, but it is better than nothing;
> it's simple, and it won't break things in the future if and when we
> finally get around to implementing the full POSIX capabilities model.
There is no obvious way to determine that an executable will drop
capabilities. You have the halting problem to deal with.
There is no reasonable way to add this feature to an existing executable.
Other than the above two problems, yeah, it was a nice idea.
----------------------
I had an interesting idea a while ago. One could encode all the logic into
the executable header as a series of load/store and math operations.
(as an interpreted byte-code, without backwards jumps)
load fI,r1
load pI,r2
and r1,r2,r3
load fP,r2
or r2,r3,r1
store r1,pP
load fE,r2
and r1,r2,r3
store r3,pE
There could be an enforced mask at the end too.
To determine what the result will be, just interpret the byte code.
Since there can be no loops or recursion, calculation would be fast.
-
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/