Re: Request for discussion.

[newsham () aloha net (Timothy Newsham)]

a lot of the response was "see trusted solaris".   Also mentioned
was AIX.  I'll take a look at these if I get the chance.  What
I'd really like is something implemented on a free base (ie.
4.4lite derived OS).

> > - 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.
>
>   Access Control Lists are also part of Trusted Solaris--it allows finer
> grain control (ie. user X is allowed to run suid prog X) at the cost of
> more administration.

I think you misunderstood me on this point.  I dont mean "dont let
user X run any suid programs" rather "dont honor the suid bit on
any files that are owned by user X".  One reason is that a common
trojan horse attack is to store away the users' priveledge by
copying a suid shell into some hidden directory.  If the user will
never need suid capabilities (most dont) then there is no reason
to honor suid bits on files owned by this user.  Rather than 
ignoring the suid bit it should fail with errno set to an appropriate
message to avoid any confusion. 

>   I implemented something like this a while back. Public key
> distribution is the main problem. The second is it takes a while to
> do the public key encryption to exchange a key. (On the order of a
> second or two, longer if you include a real public key distribution
> system). That second may not be a big deal except for services
> like HTTP which make dozens of connections. (I actually implemented the
> whole system: ANSI X9 public key distribution server, the encrypted
> socket library, and a secure HTTP client & server--if you're interested:
> http://www.c3.lanl.gov/~mcn/sunrise/sunrise_security.html)

Thats why I plan on using private keys for my own use.  For example
host X trusts host Y for user Z.  I don't want to rely on the
IP address or domain name of Y so instead I make up a random
password PW.  Now I edit the rhosts file for both machines.  On
X I put:

    Y Z PW

on Y I put

    Password X PW

now when I rlogin to X from Y, it sees username is Z, source host is Y.
Now it grabs the PW from the rhosts and compares against what Y sends.
With this scheme the IP address is used but the security does not rely
on the IP address alone.  It also relies on information stored on the
filesystem of the trusting machine.  Of course the password doesn't have 
to actually be sent.  If the link were cleartext you'd use a challenge/
response with the PW.

As far as an encrypted stream layer, I already have something
implemented and working.  Simple DH key exchange followed by stream
encryption.  I'll check out your implementation though.

>   Trusted Solaris does this. In fact, it's even finer than that--for

The list above was just what I thought of off the top of my head.
If you have a list of other priveledges that should be broken off
please send it to me.

>   Again, Trusted Solaris... I think BSD4.4 is heading in the right
> direction for a less complex system with good security. Immutable and
> append only files, along with a LOT of kerberos support is the right
> direction. Let's just hope the SysV camp doesn't blow off BSD's
> accomplishments as "research trivialities" again.

I love the idea of append-only and immutable files, but I would also
like to have tighter control over the use of suids on the filesystem.
(Other than just disabling suids on all the user-writeable filesystems).
I wish BSD4.4 had addressed access control in the network layer and
better auditing for network and processes.

> -Mike