Messages in this thread | | | Date | Sun, 28 Jun 1998 20:15:08 -0700 | From | Andrew Morgan <> | Subject | Re: Secure-linux and standard kernel |
| |
Ingo,
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
| |