MOLNAR Ingo writes:
> On Sun, 28 Jun 1998, Andrew Morgan wrote:
> > 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 ...
I had in mind a program bought from a, since deceased, start-up a few
years back with no source and an apparent need to be setuid-root: it,
for example, needs to talk with a ISA controller card and provide
services to my customers over the internet. Because of the nature of
my small business, I completely rely on this program/card functioning
reliably although its statically linked binary is a complete mystery
to me. I'd really feel a lot better if I could run this program with
the id of "nobody" and the one or two capabilities it needs to do its
work.
[POSIX, when developing their capability model, had in mind the
concerns of companies that did not run code provided with source!]
My opinion basically stems from the existing practice of letting the
kernel provide a restricted interface to modifying the contents of an
inode (file attributes) and the user be completely responsible for the
contents of a file (the data). This distinction is quite simple and
general = good from the perspective of auditing the security of a
system. It is a natural extension to store the capabilities amongst
the file attributes and have them maintained only via a
kernel-controlled interface.
> (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 ...)
This is, indeed, very flexible. I guess I just don't trust it to be
safe... Putting PGP in the kernel is not likely to happen any time
soon.
> having mount options for priviledges is indeed a very nice idea, but it's
> very orthogonal to the per-executable priviledge-mask concept.
I don't see how it is othogonal. It seems only prudent to be able to
provide the option for an admin to say, "I'd like to access this
filesystem, but I really don't trust it to provide programs that can
reconfigure my firewall.."
> 'trust' defined by the binary-loader (in the kernel) is very extensible,
> while a static bitmask stored in the inode has many drawbacks.
I'm not so sure that they are mutually contradictory though.
Perhaps it is too late for NFS to provide POSIX capabilities, but I'd
like to think that CODA could be encouraged to provide support for
them. Are there any real reasons why ext2 cannot be extended to
support them too?
Anyway, I'm not (currently) doing the work, so I am only adding noise
to the discussion...
Cheers
Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu