Re: Request for discussion.

[newsham () aloha net (Timothy Newsham)]

> > - run network daemons with lower priveledges.
> > discussion:  Why are so many net daemons run as root?
>
> I speculate because they want to bind to privileged ports.
> [Yes, I know that's not a good reason.]

Telnetd runs as root.  I haven't gone in and looked at it yet
but some things it doesnt need root for are:

   (1) Binding to port 23 - inetd does that.
   (2) Setting the users id - login does that.


> Several times, I've been frustrated because I've wanted to
> run my own (non-root) personal copy of in.telnetd or somesuch
> with my own program in place of /bin/login.  This would be
> a very useful feature... but alas, it doesn't work on any
> machine I have an account on.

I have done this.  Grab telnetd sources and modify.  Quite easy to do.
(Would be nice if telnetd took a command line option for this
so that you didn't have to rebuild for each program you want to run).

> Not a bad idea, but most likely there'd be links from /usr/bin/ps
> to /usr/suid/bin/ps... :-(

If /suids was added to everyone's path in login or system wide
cshrc/profile/login the symlinks wouldn't be needed.  I know some
people would still put the symlinks in, but I think it should
be discouraged.

> > - system list of users allowed to use suid and sgid.  Suid
> >   binaries not run if file owner not allowed to use suid/sgid.
> > rationale:  reduce the ability to store priveledge on a filesystem.
>
> Too many programs are setuid -- for example, some mailers need
> to be setuid to maintain spool permissions, etc.  I doubt you'll
> find anyone who can get by without a single setuid program :-)

I think most people misunderstood me on this point.  I meant
"suid bit not honored if file owned by user X and X not allowed
suid priveledges" rather than "user X cant run any suid programs".

> This is an excellent goal!  (though I don't like the trust server
> bit, centralized points of attack are best to avoid, if possible,
> right?)

If you're going to trust a host at all (which people seem to always
want to do) I think there will be a centralized point to attack this
trust.  For example any priveledged user on the trusted host can
become any of the trusted users and connect to the trusting host
without authentication.  The only way around this is to not
support "trust" at all.  I think trust is a very useful thing though,
some hosts are "equivalent" (all accounts exist across both machines).
Some hosts are "greater than" and should be trustable from the "less
than" hosts.  Of course sometimes trust shouldnt be used, and it should
definitely be minimized.

> One problem I see is that most of those privileges are equivalent
> to root, in the sense that if you give me {kmem,net,console} access
> I can get root access quickly.

I dont think priveledges should be broken off if they are "equivalent".
Ie.  if I can get root 100% of the time from net, then net shouldn't
exist.  But if it can be made secure (ie.  net can be made secure
by end-to-end encryption and/or authentication protocols) then I
want to seperate the priveledges as much as possible.

> > - uid/gid passing over sockets.
> How would this work for anything other than AF_UNIX sockets?

For uid's it shouldn't.  I believe fd's can only be passed over
AF_UNIX sockets.  With a capabilities security model it should
be possible to pass capabilities over the network.

> David Wagner                                        dawagner () princeton edu