> I will inject my opinion about where to store the capabilities. I do
> not feel it is appropriate to put the capabilities within a file.
> There are a number of potential holes here, but my main objections are
> that it makes the task of the administrator harder, and it offers very
> limited support for old "legacy" applications. [...]
if it's old 'legacy' (you must mean some binary in a.out format), and it
has to do with security, it cannot be very secure ...
if it's some script, there was a very nice perl script posted recently. As
scripts have their own security problems anyway, it's not bad from the
security point of view to split concepts.
if it's an ELF binary, we can add a NOTES section without recompiling the
binary ... 'chpriv'.
(just to show how robust the concept is, compared to the in-filesystem
solution: this little utility can be extended to add some MD5 or PGP
signature of the binary to the NOTES section too, which is also stored in
the kernel, and cannot be modified afterwards ...)
> [...] Ultimately, I would
> like to see some filesystem support for capabilities to be stored as
> file attributes. In the original linux-privs patches for 2.0.*, we
> extended ext2 to have such support and it worked fine. I really can't
> see what stops us from doing that for real... As Alan Cox has
> indicated, having a mount mask for certain capabilities seems like a
> very natural way of extending the current practice of suppressing
> setuid binaries etc. with mount options.
having mount options for priviledges is indeed a very nice idea, but it's
very orthogonal to the per-executable priviledge-mask concept.
'trust' defined by the binary-loader (in the kernel) is very extensible,
while a static bitmask stored in the inode has many drawbacks.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu