> >> 1. Put capabilities information in the executable header.
> >> 2. Mark the executable setuid root.
> >> 3. Have the kernel check for #1 if #2, and prefer #1 if present.
> >
> > That confuses everyones security scripts. It makes the binary run as root
> > on an older system, so if you downgrade you get a massive security hole
>
> You have that backwards.
My drunken state causes me problems with a few things, but Alan's solution
still looks good to me. If the kernel doesn't perform the #3 check then
you have an unexpected setuid binary on your hands...
> 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...
> If you downgrade the kernel, you need to have the binary run as root.
> Anything else would give you a broken system. Executables with
> capabilities need to be just as secure as setuid executables anyway,
> since they grant privilege when run. Kernels that support capabilities
> (in the header or otherwise) would only contain the damage a bit.
>
> So the executable header method is actually a bit more secure when
> running a new kernel with old scripts (likely), and it still works
> in a normal setuid manner with an older kernel.
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,
2. The magical granting of these privs is done _only by privileged
code_, and
3. (Somewhat controversial) such processes are subject to additional
security paranioa, similar to (yet at a much lower level than)
Perl's "tainting".
> 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.
Trivial things might be OK, but things like persisent capabilities which
might break old kernels are carefully examined by sharper eyes han mine..
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...
-
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/