lkml.org 
[lkml]   [2003]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: posix capabilities inheritance
From
Date
Andy Lutomirski writes:

> I agree with these problems, but I think the proper
> fix is complicated. AFAICT, POSIX capability
> evolution, as specified by whatever draft it was,
> is broken, so the hacks in prepare_binprm
> (cap_bprm_set_security in 2.6) are needed to avoid
> security problems. Aside from the fact that
> non-inheritable-by-default makes little sense
> (and requires root to get capabilities re-added
> from the file _permitted_ set), POSIX cap
> evolution has some other problems:

You've noticed! :-)

The people who wrote the code were working from
two different drafts of the spec. I think some
people used draft 16, while others used draft 17.
(or 15 and 16, or 17 and 18 -- a difference of 1)
Between these two drafts there had been BIG changes.
Well, a critical equation changed.

People at SGI, mindlessly cloning the IRIX code,
stuck us with the half-ass set of capability bits
we have today. They ignored the DG-UX implementation
using 256 bits and slightly different equations.
They ignored the fact that the security model will
be terribly inconsistent if you still have apps
making UID-based decisions -- that is, you need to
allocate bits for glibc, XFree86, Linux vendors,
admin tools, various databases, and local site usage.
Yes it's yucky, but it's required. Covering ears
and burying the head won't make this go away.

Nobody thought to have half the bits default
to "on" for stuff currently allowed for regular
users. For example, the right to listen for
incoming network connections could be limited
if this had been given a default-enabled bit.

Then there's the emergency hack done to patch a
security hole that the capability bits introduced.
I think that was back in the early 2.4.x days.

People like to ignore the fact that apps tend
to answer "Do I need setuid-style precautions?"
by examining UID.

People like to ignore the fact that privileged
code, written with setuid in mind, can lead to
all sorts of mayhem if 42% of the privileged
operations are prohibited. Yeah, you'd hope
that a setuid app has great error checking and
can cope... but "hope" shouldn't satisfy you.
We really need a way for app authors to mark a
binary as "always block rights P, Q, and R" and
"block all rights unless given V, W, and X",
with the assumption that an unmarked app requires
an all-or-none situation.

Probably there should be two worlds on the
system. Apps with "funny" rights should be
kept away from UID 0 and setuid apps, while
apps with UID 0 or setuid should be kept
away from "funny" rights. Give the init
process a special ability to cross worlds.

The authors of our code seem to have given up
and moved on. Nobody cleaned up the mess.
Is it any wonder the POSIX draft didn't ever
make it beyond the draft state?

(and damn, WTF is with !capable(...) meaning
that you are capable of performing something?)

One final horror: just imagine trying to write
up some sane documentation for the average admin.
Poorly-understood security mechanisms are a
hazard. BTW, don't forget to imagine documenting
all the interactions with UID, filesystems, etc.

Face it: admins will think in terms of assigning
rights to users, never minding that there are
some weird equations, UID interactions, and
perhaps per-executable bits.


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.031 / U:0.488 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site