Re: server-based auth

Hi,

Erik Quanstrom wrote:
>
> >For your scenario, the msg_connect() system call should be disabled. The
> >process could then walk down current mount points, but could not access new
> >servers. Other possibilities are disabling fork()/tfork()/clone() (perhaps
> >a couple others). This would create an execution environment in which a
> >process could serve requests but not much else.
>
> why not let the servers themselves do the authentication, a la
> the 9p? as in the message set

The problem would be that most servers have certain default permissions that
allow all users to be able to see certain things (albeit usually read-only).
In this case we don't really want that to happen. By disabling the
msg_connect() mechanism we stop a process from establishing any new
connections and thus accessing anything that they don't currently have
access to.

Thinking about this it would appear that we ought to be able to define
another standard ID (much like the sys.sys id) that doesn't have the right
to perform certain system calls. Perhaps this should be a no-one id that
any user can create? Anyway the idea would be that a user who execs a
firewall type process would establish the limited connections under their
normal id and then relinquish this completely in favour of the limited id
(easy to do)

I don't think this should cause any security risks as the no-one id doesn't
allow anyone to do anything new - if the disabling is done correctly (as in
login) there's no way to get back once we're running as no-one :-) The
other nice thing about this is that we can allocate each no-one a sub-id
that means they can't possibly mess about with each other's work.

Have I missed anything drastic?

                                Regards,
                                Dave
Received on Thu Mar 16 11:38:48 1995