Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
Re: Request for discussion.Timothy Newsham (newshamaloha.net)
Mon, 6 Feb 1995 10:30:10 -1000 (HST)
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Timothy Newsham: "Re: Request for discussion."
- Previous message: Martha Lanatte: "Re: nfsbug, bugs"
- In reply to: Michael Neuman: "Re: Request for discussion."
- Next in thread: robert owen thomas: "Re: Request for discussion."
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