You don't have to sell shell accounts. The past 12 years I worked constantly for companies that had one or more unix servers and always only a small number of users had an admin account, all other had 'normal' user accounts.
Even today we share one linux box with several users. (Each user has a Windows Computer at his desk, and uses W-WinPro to access the central development server). And not every body has/knows the the admin account. Even on a single user system I wouldn't recommend to work constantly as administrator (neither under windows nor under linux). I prefer to work always with the least possible rights, so that any virus that might come in, can do fewer harm. (in this sense I don't trust even myself, although I was never infected in all those years) Yes, the solution to this problem is clumsy. Yes, something like service/capability based ACL's for processes would be a better mean to do that. On the other side, I have problems to imagine a solution that is manageable. (unlike the handling of rights under Win2000/Exchange). All the solutions I've seen in the past for trustedxxx, had nice features but where so difficult to configure and maintain, that it was hard to get more security whithout affecting the ease of use for the daily work. > -----Urspr�ngliche Nachricht----- > Von: Dr. Evil [mailto:[EMAIL PROTECTED]] > Gesendet: Freitag, 7. Dezember 2001 09:20 > An: [EMAIL PROTECTED] > Betreff: Re: AW: security issue: tomcat on port 80 <snip/> > Which is plain old stupid, I must say. It's not like Yahoo sells > shell accounts on www.yahoo.com, right? It dates from the good old > days (now long gone) when root/sysadmins users basically trusted other > root users, but didn't trust their own misbehaving shell account > users. This is totally irrelevant on today's Internet. In the old > days there had to be many users on one machine doing different things > because machines were expensive. Machines today are not shared. They > are owned and used by single entities, and for server machines (like > www.yahoo.com) the only people with access to the machine are ones who > already have root access. Either you trust the machine and all of its > sysadmins and users, or you don't. How many companies still sell > shell account service? This OS limitation no longer has any security > upside, and it has a huge downside, which is that the same process > which runs CGIs or servlets also has (at some point) the power to edit > /etc/passwd, and similar things which it should not have the > capability of doing. > > The ultimate solution for this is capabilities based security. At a > very fundamental level, I should be able to give a proc the capability > to bind to a port without also giving it the capability to edit > /etc/passwd or read arbitrary RAM. The "uid 0 to bind < 1024" > restriction just makes things worse. > > I'm still waiting for TrustedBSD which will implement all this. > Pretty much every exploit known in the Unix world has, as one of its > steps, or as its end goal, getting root. The solution to this is to > not have root, obviously. <snip/> -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
