Security

Ask something
Discussion Locked

Beef up UNIX security with ACLs

0 helpful
9 replies

by debate

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

What suggestions do you have for bolstering UNIX security? What experience do you have with using access control lists on UNIX systems? Share your comments about enhancing UNIX system security, as discussed in the Feb. 28 Internet Security Focus newsletter.

If you haven't subscribed to our free Internet Security Focus newsletter, sign up today! Click this link to subscribe automatically:
http://nl.com.com/MiniFormHandler?brand=techrepublic&list_id=e044

9 replies

by jdmercha

Bolster Unix security? I thought Unix was perfect. After all is is open source. And only Microsoft software has security holes.

by jaqui

not perfect.
far better than windows.
and not open source.
unix itself is commercial
linux, irix, free/open bsd, sun solaris are open source.
none are unix they are clones of unix.

by jdclyde

Too bad this isn't one of those times.

Buy a clue and get out of the propaganda war until you learn a little bit about it. You just make you and the rest of the Windows Zombies look even worse than you are.

There is no one perfect answer. Open your mind and use the right tool for the job.

(unless your just out trolling dispite looking completely uninformed and clueless?)

by jaqui

the basic.
use secure passwords, with regular expiry, auto assignment through random generation of passwords.

properly configured firewall.
no running servers you don't require.
be brutal on permision for the system, lock users from affecting system other than thier own files.

just basic security for unix, or posix compliant os.

by stress junkie

I got tired of waiting for the newsletter.

Having come from years of running Digital Equipment Corp's VMS, the best damned enterprise class operating system ever written, I have a lot of experience using access control lists. I believe that ACLs can help to fill in the gaps for very specific situations where other object protection mechanisms are too broad. ACLs can also create numerous problems for a system administrator when they are used in excess.

In Unix and M$ your first layer of object protection is object ownership. Objects can be owned by a particular account and a particular user group. Access can be granted based on basic protection/access settings. The more that you can do with this level of configuration the better. Keep it simple.

In Unix the group permissions can be very flexible. Unix has the ability to assign secondary group membership to a user account. This is very similar to the rights identifiers in VMS and they can be used in the same way. One typical use is to have device files owned by the root user but some secondary user group. For example the cdrom device is owned by the root user but it is also owned by the cdrom group. Any normal user can be assigned to the cdrom group. Access to the cdrom device can be controlled by setting the permissions on the /dev/cdrom file. Any user that isn't root and doesn't belong to the cdrom group will not be able to access the cdrom.

You can do a LOT with file ownership and secondary user groups.

The problem with ACLs is that they can get very complicated. If the ACLs for a given directory or other resource is complicated it can be difficult to determine the reason that user x is having trouble accessing resource y. When a new system administrator comes in, as I did many times working as a contract employee, the extensive use of ACLs can be unexpected. I remember one case where the previous system administrator had used ACLs as their primary access control to system resources. After a few end user problems were resolved I decided to rip out all of the ACLs on the file system and start over creating access controls based on basic file ownership permissions. That system was a lot easier for my successor to administer when I finally left that job. Problems were easier to diagnose and correct.

So, while ACLs can be useful in some situations I would advise anyone to seek a simpler solution first. When file ownership and basic permission settings just won't do the job then consider using access control lists.

by stress junkie

I enjoyed reading the newsletter mini-article on which this discussion thread is based. I can't fault you for spending more time discussing Novell than VMS. I'm guessing that most people have never heard of VMS. Too bad, but that's DEC's fault.

One point that you mention at the end of the article was that many Unix sysadmins give blanket access to files because of their ignorance of file system security. That was also a big problem in VMS. Anyway, regarding Unix, I have spent, and continue to spend, a lot of time experimenting with file access settings. The default settings from the installation of any Unix that I've seen always seems to reflect a time when security was seen as an unneccessary burden. Back in the 1960s and 1970s many multiuser systems were thought to be inhabited by a community of trusted users. The idea of hiding or securing system files from these users would have been considered insulting. That was then and this is a different world, but the default file access settings in a Unix system still reflects this open door approach.

Some of the things that I'm trying on my home computers is to make most of the top level directories owned by root:users with drwxr-x--- permission. This keeps the directories inaccessible from accounts that are neither root nor in the users group. Accounts like nobody, ftp, mail, and other function specific accounts. I'm still playing with this.

Another idea is to make the /etc/*.conf files inaccessible to nonsystem accounts. After all, why let curious users look at the system configuration?

I've just about determined that the 'requirement' to have the /etc/passwd file readable by world/other is simply to allow certain unneccessary utilities like finger to work. Therefore I've set that file to world/other noaccess while maintaining the root:root file ownership with no ill effects. I haven't tried this on a production system yet. I don't believe in letting users run finger. I'm about to play with restricting access to the /proc directory. Normally privileged users can see just too darn much about the system and running processes when /proc is configured with its typical access settings. I haven't actually tried changing this yet. Maybe the system will refuse to boot. I don't know. Anyway, this is the sort of thing that I enjoy testing.

Given all of that I still say that ACLs can be useful when you have a very detailed file access situation. Normally, however, the use of Unix secondary groups can provide a pretty high level of file access flexiblity. Even if you never allow world/other any access to data files, for instance, you still have two levels of access to play with in the old style file access control. The file is owned by a user account and a user group. A little imagination can help you get a lot of mileage out of this simple scheme.

So I reiterate from my original post: Use ACLs only when you absolutely need them. ACLs can quickly become very complicated. Use ACLs sparingly and you will save yourself a lot of headaches troubleshooting resource access problems.

by praetorpal

Your 2 posts touch on many important points. Nothing like the voice of experience.

You might be interested in knowing that Trustifier, which we are now bringing to market for Linux, will likely be ported to the BSDs later this year and deals with a number of the issues you have mentioned, allowing superb access control without the complexity, and the headaches.

by raggedyman

NOt everyone ignored Banyan; there was a reason the USMC used it - it was secure. Unfortunately, it no longer exists, M$ bought it & killed it. However, they had the foresight to higher all of the StreetTalk (Vines security/naming system) prior to killing it. Netware also licensed StreetTalk years before M$ killed Vines.

Vines ARLs (Access Rights List) is similar to M$ ACLs. The big difference is that whereas ACLs work from the top down, ARLs work from the bottom up. This means that in Vines you control access at the root & open it up for users to use resources as you go down the tree to the resource. To my mind this was more secure. Windows seems to like having it totally open at the top (using 'Everyone') and if you tighten security too much at the top, it causes access problems further down.

But then, what do I know? I was a Vines administrator for only 10 years and I have been a Windows administrator for only 8 years. M$ has come a long way, but it isn't out of the woods yet.

by magpiper

POSIX file permission are horrible at best and are difficult to manage and highly confusing. I should not have to calculate rights assignments in my head, the OS should clearly provide this. NTFS rights tend to be confusing and over-complicated. Novell Storage Services (NSS) file permisions are hierarchial and flexible. For instance in no other file system that I know of can you filter specific rights from files/directorys.

Currently I am attempting to backup UNIX and NTFS file permissions and atrributes only by dumping them to a file. I have yet to find a simple way to do this. Netware provides TRUSTEE.NLM that will backup any rights and attributes.

The GOOD NEWS!

With the release of Novell Open Enterprise Linux/Unix OS has a new choice for a file system. Now you can have the simple/effective file permissions and storage management that NSS offers. I have worked with DOS,NTFS,EXTx,ReiserFS,Netware and NSS. I have yet to find a more powerful and forgiving file system than NSS.

The Open Source community should develop or adobt NSS for Linux, as it would greatly improve the Linux file system. I hear rumor that NSS will be released as Open Source soon if not already.

This discussion is closed to new replies.