Tim Newsham wrote:
>
> I think VSTa's
> approach is quite nice, it easily allows processes to make
> up their own capability definitions and still use the standard
> library routines to manipulate them. It also has a convenient
> mechanism for giving away weaker versions of a capability and
> an easy mechanism for disabling priveledges that one has.
This is a big advantage as far as I'm concerned - the only POSIX thing we
can't really do is handle a user belonging to several different groups. In
practice I'm not sure that this is such a big issue anyway, but as our users
can currently hold several IDs this should cover most cases.
> I think this system *could* be used to make VSTa a very secure
> system. (I emphasize "could" because the primitives are just
> a tool, putting them to work is still a lot of work).
As part of the work I've been doing on pstat I fixed a couple of bugs in the
1.3.2 permission code and it now seems to provide some very neat protection
facilities. I just reworked some of Bjorn Helgaas' proc code yesterday and
found the ability to be able to derive a permission given a shorter one (or
any permission if we have <root>) and to be able to enable and disable any
permission we have offers some really nice tricks. The proc code, for
example, can now assume the identity of each of its clients in order to get
kernel information without requesting information based on its own
permissions.
I'm sure there are more subtle uses that could lead to a very secure system
- the biggest problem I envisage will be with security of a distributed
environment.
Regards,
Dave
Received on Sat Dec 10 03:44:12 1994
This archive was generated by hypermail 2.1.8 : Thu Sep 22 2005 - 15:12:10 PDT