If the kernel doesn't perform the #3 check then your system will not
function correctly without a setuid binary.
Look at it this way:
You already have a setuid-root binary.
This hack lets you reduce it to be merely a capability-enhanced binary.
If you boot an old kernel, you are back to the original condition.
With the other system, you simply must not ever use an old kernel.
You would have filesystem trouble (files you can't safely remove)
and general app failure (inability to use privs). At least my solution
lets you boot an old low-security kernel if you need to.
>> If you add capabilities information in the filesystem, all your existing
>> security scripts will FAIL to detect privileged executables. That is bad.
>> The presence of a setuid bit will be detected by older scripts.
>
> If you change the expenected Unix (Linux) protection machanisms (only the
> kernel can grant such wonders as low ports, raw sockets, &c) you will
> break a hell of a lot more...
Yes, but that doesn't excuse privileged executables that are needlessly
difficult to detect.
> No, it's horribly broken. If you provide an additional way for a binary
> to acquire privileges, you must at least check a few things:
> 1. Old binaries (and people making and "pretending" to make them) are not
> able to acquire these privs,
No kidding. You don't just let anybody make setuid-root executables.
Don't think "acquire these privs", since a setuid-root executable
already has _more_ privs with Linux 2.2.5. It would lose some of them.
> 2. The magical granting of these privs is done _only by privileged
> code_, and
The kernel already checks for this. (you can't make a setuid-root bin)
> 3. (Somewhat controversial) such processes are subject to additional
> security paranioa, similar to (yet at a much lower level than)
> Perl's "tainting".
The kernel already has a process flag to handle this.
>> Then remember compatibility with archives, fsck, NFS, old ext2 drivers...
>> The header solution is just less complicated and more reliable.
>> (those being important qualities for a security feature)
>
> From the start (I'm not old enough to get the whole picture, but have been
> avidly reading the source recently) ext2fs was designed to be entensible.
Yes, we _could_ extend ext2. Then we need to extend everything else,
from NFS to tar. That includes non-Linux NFS servers.
> Short summary:
> Bollocks. You seem to forget that any user process can reda, write and
> create executable files. And that, inded, these files can provide dynamic
> loading services...
Any process can write to a setuid-root executable? You have a serious
security problem that you should fix.
BTW, the header could be quite powerful:
euid = (left as the user)
ruid = (left as the user)
suid = sybase
fsuid = mail
extragroups = foo, bar, baz
P_priv = CAP_FOO, CAP_BAR, CAP_BAZ
E_priv = CAP_FOO, CAP_WHATEVER, CAP_XYZ
I_priv = CAP_FOO, CAP_USEFUL_THING, CAP_STUFF
-
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/