Having read the POSIX.1e draft I can say you are also correct in so
far as it is mostly a mess! :^)
However, the capability part of the draft is IMHO extremely well
thought out.
They decide on a need for file attributes to specify the capabilities
that a program can acquire as this is the most straightforward way for
the sysadmin(s) to keep control of the system: in general, the model
assumes that the security/reliability of "trusted" filesystems is
guaranteed.
My problem with things like CAP_SETPCAP is that it is ill defined: it
places a large hole in the security model of the kernel and leaves it
up to a user application to fill. I can see that in your language,
this can also be read as "open to a world of possibility..." :^)
Currently, the software security perimeter of the Linux kernel is the
system call API. Adding CAP_SETPCAP for the express purpose of giving
arbitrary capability control to a user space daemon seems like a
really dramatic change.
Perhaps it is just semantics, but this sort of ability seems to be
much more appropriate to a "security module" than a user-space daemon.
> As such, we should _allow_ the capability to raise other capabilities. If
> you don't like that capability, you can just make sure that it is cleared
> at boot for everybody, and then nobody can inherit it and nobody can ever
> get it any other way either (as nobody has the capability to raise the
> capability).
By definition, your opinion is the one that counts.
I guess if I have to concede on this can I suggest that, at the very
least, this should be a global is_secure(ALLOW_SETPCAP) condition?
Otherwise, the "nobody can inherit it" part is only good as long as
there is no executable sitting on a trusted filesystem that has this
Permitted (Forced) bit raised. (Some protection against the equivalent
of the current "setuid-root shell" that people like to have lying
around... :^)
Cheers
Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu