On Sunday, November 17, 2002, at 11:09 AM, Kee Hinckley wrote:
Used properly, ACLs can create a system, that is much more secure, because you can restrict access to certain parts of the system to specific processes that need to use that sub-system. However, with the exception of the OpenBSD folks, hardly any Unix vendors have taken advantage of even the *Unix* file permissions to do this. As a for instance, you shouldn't have to become root to install a printer, or install a piece of email system software. You should only have to become a member of the group which manages those components. That kind of distributed authority makes it much harder for a virus or worm to gain complete access to the system. A worm that subverted the mail system, for instance, would solely have access to the mail system, nothing else.We're saying much of the same thing, however, this problem which you describe is not an OS or vendor level problem and not even an ACL problem. It's a programmer/admin attitude problem, exemplified by the constant stream of questions asking how to login as root under OS X, or why they can't su to root anymore. It's a basic mentality; a way of thinking about the problem - issue.
The concepts of distributed authority are simply foreign to the Unix (and Linux) community. And the problems are acerbated by the fact that the traditional Unix System Administrator still expects to do everything as root. The vendors are just responding to customer demand -- or more accurately, the lack thereof -- for security features. Tru64 Unix (aka OSF/1 aka Digital Unix) has supported a C2 environment out-of-the-box since it's first release back in about 1990. But is it used? No. The few who wanted "enhanced security" only wanted a "shadow password" file, because that's all that BSD and Sun offered. They were not interested in taking the time to learn the ins and outs of C2 because "we don't need that level of security."
The basic attitude of Unix programmers is that they must have root access in order for their program to work "correctly." Permissions are simply too difficult to understand, and under Unix far too restricted in their capabilities, too inflexible, and too difficult to administer. Sendmail is a classic case in point. For years it has run as setuid root because that's the way you did things in Unix. Only very recently has there been a movement to make sendmail operate in a non-root required manner. The other cause is the fact that daemons started by the boot process ran as children of root, and it took too much effort to do it any other way. The BSD community has traditionally rejected the System V attitude that there should be separate userids for separate functionality. It has only been in recent years, since kiddie crackers using automated scripts became a problem and the use of Unix moved into the Enterprise space, that the Unix community has begun to deal with these kinds of issues.
Prior to Unix's move into the Enterprise, the so called "Proprietary" operating systems dealt with security issues on a very different basis -- example... the person who created accounts was NOT the person who issued the passwords for those accounts, and the System Administrator was responsible for neither function! But that is not the Unix way.
T.T.F.N.
William H. Magill
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
