Unix permissions model

Softpanorama main  > Access Control in Operating Systems

Unix borrowed from CTSS a simple model of file permissions and somewhat extended it. This model which is called Classic Unix Permissions models has proven to be amazingly effective, flexible and easy to understand. All those three signs of great design are present in it. And in retrospect it proved to be not that simple. But it is still within intellectual capabilities of most Unix sysadmins. And that's a great achievements as many alternatives and extensions are not. For example, recently, there was an attempt to extend Classics Unix permission system  using ACLs to compensate for its fundamental weakness: file can belong only to a single group. ACL model is similar to approach to file permissions that is used in Windows  but it is so complex, that very few organization have adopted this approach on Unix servers belong some trivial cases of exported via Samba or NFS filesystems.  And very few sysadmins understand it, and even those who understand vary of using it. This lack of adoption had shown critical importance of complexity in operating system permission model. Also the existence of two models in Unix is an additional (and huge) negative factor which not only confuse administrators and represent a serious security risk.  The effect quite opposite of intention. As in the saying "roads to hell are paved with good intentions." 

Unix implements a variant of  Discretionary Access Control (DAC), meaning that each user decides which of his own files is accessed (read, written, or executed) by other users. The system itself is protected from tampering by having all system files owned by the administrative user 'root' or some "placehoders" with no login capabilities (bin, sys, adm). Typically each application is assigned a different user ID, thereby isolating and protecting the application data from all other applications. This is the reason why without access to root it is quite difficult, if not impossible, for a legitimate application to steal the private data used by another application (unless, obviously, that data is set world-readable).

In the original Unix model, each file has just three access categories of user: User (u), Group (g) and Other (o). Group is essentially a role and primary group is a primary role for a particular user. Any user can be a member of any number of groups, but unfortunately groups can't contain other groups.  So all groups in Unix are "prime groups" consisting of users. In my view this is the most serious blunder of the Classic Unix model. Of course you can "precompile" /etc/group file creating the ability to use other groups as members of groups via backdoor . This way you can introduce "metagroups" -- groups that are aggregations of existing groups and users, not only users as in "prime groups". But that solution  requires additional efforts and discipline (in this case /etc/group need to be automatically generated from some template with macros).  If we assume that the number of group allowed is large (approximately the same as the number of files/directories) metagroup approach is as powerful as ACL model and is much simpler.  It requires relatively simple modification of the /etc/group file.

There is also auxiliary concept of  system groups which is similar to the concept of privileged ports. For example, all groups with GID below 100 are often considered to be system groups.  System groups has special properties, and designed mainly for partitioning of permission space. For example, most users which have system group as primary group have no legitimate shell (/bin/noshell or /bin/false is used instead; the former logs in access attempts), so nobody can login as such a user.  In other words the numeric value of group partition groups into two categories with lower value groups considered to be more privileged. Again this is a similar idea to the idea of privileged ports and despite its simplicity is quite powerful and permits additional checks via PAM mechanism that increase security.  One such privileged group is called wheel and it can be used to limit the ability of users to switch to root, independently whether they know root password or not.  This idea of wheel group like many brilliant ideas came from BSD.

One pretty recent interesting extension of Classic Unix model is the concept of  User Private Groups (UPG) introduced in Red Hat.   This is simply a new convention for assigning primary groups to real (human) users. Whenever you create a new user, by default, he or she has a unique group that has GUD equal to UID.  UPG scheme makes UNIX groups easier to use and make home directories more secure. This is just a procedural enhancement, which does not add or change anything in the standard UNIX way of handling groups.

Read More...

• Introduction
• Unix file permission structure
• Inheritance of permissions
• Directory permissions
• The concept of trusted path
• Ownership issues on directories
• Symbolic mode of chmod
• See also

NEWS CONTENTS

• 190813 : Adding "disabilities" to Linux ( )
• 190813 : Chapter 3. Computer System Security and Access Controls by Deborah Russell & G.T. Gangemi, Sr. ( July 1991 )
• 190813 : Self/Group/Public Controls ( )
• 190813 : Access Control Lists ( )

Old News

Adding "disabilities" to Linux

From Ron Arts on 25 Jun 1998

Hello,

I saw a post by your hand from 26 Apr 98 in comp.os.linux.development.system where you said a lot of noteworthy things on linux security. Also I have been talking to Jos Vos from Xopen Systems (who wrote the ipfwadm package).

Both you and he noted the possibility to break out of a chroot jail (once you become root there). It seems that devices are the weak factor.

It seems that letting anyone "become root there" is the weak factor! If we can reduce the need to "become root" --- by providing mechanisms other than "SUID" and "SGID" programs for accessing "privileged" operations than we have made some progress.

One approach would be the POSIX.1e "capabilities" (which are more like VMS style "privileges" than true "capabilities"). There is a bit of preliminary work being done on this in the 2.1.x kernels --- but nothing is likely be usable in 2.2 (so you're looking at Linux 2.4 before there is "stable" support for any of that).

Another approach is to limit the damage that 'root' can do using something like the BSD securelevel features. Last I heard on the Linux kernel mailing list they had dropped plans to put in simple 'securelevel' support in favor of a "more flexible" approach --- which would mesh better with the eventual POSIX.1e ("Orange Book") work.

• (The implementations of 'securelevel' in all of the popular BSD variants, free and commercial have been vulnerable to a few attacks via the /proc filesystem and more recently via ptrace() --- so having Linux adopt one of those designs might not be a sound idea. We'll see).

I'm a little shy on the implementation details and design but I think they said it would essentially be a bit field of limitations that would be set on a per process basis. There would be bits to prevent various syscalls like mknod(), chroot(), mount(), etc. In the POSIX.1e model this would later become the "maximum privileges mask" --- and the individual privileges would be set by meta data on the executable files (think of that as a list of about 80 "P" bits rather than just the SUID and SGID bits we have now).

The argument for this is that we could set any set of this bits we want on the 'init' process (PID 1) to accomplish the same limitations as we get with BSD's 'securelevel'.

That's a pretty compelling argument so far as I'm concerned. My main hesitation beyond that has to do with code complexity. The BSD crowd has been trying to get their 'securelevel' implementations right for years --- and the ptrace() bug was just found a couple of weeks ago.

It's not a simple problem. NT's "object" model (and I use the term "object" very loosely) provides ACL's on files, registry keys, and all sorts of other OS elements. There is work underway to add ACL support to Linux --- over some filesystems at least. However, I'm convinced that ACL's are a fundamentally flawed security model --- and that opinion is based on some pretty good academic work.

Unfortunately the true capabilities security model entails a completely different programming paradigm --- it doesn't translate to Unix conventions at all. In my research (purely "armchair" or "book larnin'") I spent most of my energy trying to unlearn the Unix, Netware, and NT approaches.

You can read more about the capabilities security model at Jonathan Shapiro's "EROS" (extremely reliable OS) web site:

http://www.cis.upenn.edu/~eros/

(EROS is an ongoing research project which will hopefully eventually be available as a production operating system).

I have been thinking about disabling the mount() or better the mknod() systemcall when executed from chroot'ed programs (patching the kernel).

I think the "capabilities" (or Linux "securelevel" or "privmask") patches will allow you to disable access to these sorts of syscalls. I also suspect that these "disabilities" (a more apt description really) will be inherited by all forked processes. They will certainly need to be immutable (by the process) and will have to imply certain disabilities with regards to kmem and /proc access by the 'root' processes that are running within these process groups.

You can look at the existing patches (in the recent 2.1.1xx kernels) and possibly build on that.

Do you think that would be worth the effort? We currently run ftpd, telnetd, sshd and some more things chroot'ed in a very minimal linux environment. Based on the false assumption that even when you make it to becoming root you cannot break out of that.

The assumption that the chroot() jail is inescapable by rogue root processes is very bad. You've discovered that.

The main advantage for chroot() have to do with limiting the number of SUID/SGID programs that are accessible in the effort to exploit various vulnerabilities that are used to get root or other unauthorized access. The other advantage is that you can limit the amount of snooping that a class of users (anonymous and guestgroup ftp, for example) can perpetrate on other users on the system.

In other words you can limit the exposure of your "general" users from some classes of other users. For a long time the most important element of this was to prevent FTP users from grabbing your passwd file and running 'crack' on it. With the advent of shadow password systems that has been much less of a concern.

These days the most common approach to securing systems is to create special, sacrificial hosts for each service and class of users. Linux and {Free|Net|Open}-BSD have made this an increasingly economical and attractive option since we can put any old "junker" 386 or better to work in this sort of role (some people are giving away 386 and 486 systems these days). This is easy enough for commercial sites --- but more of a problem for ISP's and educational sites, which traditionally still have shell access to at least some of their machines.

I think very few programs use mknod(), and that probably are the programs you wouldn't allow in a chroot'ed environment anyway. I also think it would be a relatively small patch, I've done some digging and - not being a kernel expert - it seemed pretty easy. The only thing left to find out is how to detect in the kernel that the current env is chroot'ed.

The kernel obviously already tracks the 'root' directory (device:inode) for every process. I think it's a field in the uarea struct (a data structure maintained by the kernel for every process).

Can you offer any thoughts on this, I'd like to know if I am on the wrong track (again) here.

Thanks in advance,
Ron Arts
Netland Internet Services

Look at the existing (2.1.x) sources for references to "securelevel" and "capabilities" --- I'm sure they're in there somewhere. You can also consider contributing to the Linux Security Audit project. See the following URL's for more details:

The Linux Weekly News article on it (search on the keyword "audit"):

http://www.lwn.net/980625/

Their currently archives/web site:

http://www.nas.nasa.gov/Pubs/Mail/archive/linux-security-audit/

If your organization needs these features and is willing to donate some web space and some personnel time and expertise to the project --- you'll be doing yourself and all of us alot of good.

Chapter 3. Computer System Security and Access Controls By Deborah Russell & G.T. Gangemi, Sr.

July 1991

File types and file protection classes provide more powerful access mechanisms. Some systems let you assign a file type or a file protection class when you create a file. You can pick from a limited set of options for file access. Many systems let you define a file as a public, semipublic, or private file. The Wang SVS/OS CAP 1.0 system provides the following choices for a file protection class:

Blank

Public. Anyone can read or write the file.

@

Execute-only. Anyone can execute the file (run the program). Only the file owner and the system administrator can read or write it.

$

Read-only. Anyone can read or execute the file. Only the file owner and the system administrator can write it.

#

Private. Only the file owner and the system administrator can read, write, or execute the file.

A-Z

System-dependent. For example, the system administrator might set up the system so only users with access rights to class P files (defined in user profiles) may be allowed to access PAYROLL files (protected with a file protection class of P).

Self/Group/Public Controls

In many systems, you control access to your files by dividing the world of users into three categories, and telling the system what the users in each category can do to your file. Some systems call these self/group/public controls. In UNIX, they're called user/group/other (UGO) controls:

Self

You–the creator or owner of the file.

Group

A set of users. For example, all the users in a particular department may be in the R&D group.

Public

Everyone else–users other than you and the other members of your group.

Each file has a set of bits called file permissions associated with it. File permissions often have the meanings shown in Figure 3-1:

Figure 3-1: Self/Group/Public Controls

If you list your files (with the correct option) in a UNIX system, you'll see such file permissions as the following:

-rw-rw-r--   1  frank   r&d   81904   Nov 7 13:25  UPDATES

If a dash (\-) appears in place of a permission, the user does not have the corresponding permission to read, write, or execute the file. For example, in the above example, the file owner (frank) can read and write the UPDATES file (rw\-), members of the file group (r&d) can read and write the file (rw\-), and the rest of the world can only read the file (r\-\^\^\-). (Ignore the first \- above; it has a special meaning to UNIX.)

Consider a few more examples:

The CHESS file contains a game; its permissions look like this:

-rwxrwxrwx   1  libr   games   61799   May 19  10:11  CHESS

Everyone can read, write, and execute this file.

The SRC95 file is a segment of code that several people in the r&d group are working on; its permissions look like this:

-rw-rw----   1  sarah   r&d   55660    Dec 19  11:42  SRC95

The owner and the other members of the group can read and change the file. No one else can access it at all.

The self/group/public controls are a good way to protect files. But what happens if you need to protect a file in different ways for different users, or if you want to keep one user from accessing a file?

If Sarah owns the FLAG file and wants Joe (a member of her group) to be able to read and change it, she'll specify the following permissions:

-rw-rw----   1  sarah   r&d   22975    Jan 19  10:14  FLAG

If Sarah wants Joe to be able to read FLAG, and Mary to be able to read and change it, she could make Mary the owner of the file (with r and w permissions) and leave Joe as a member of the group that can read (r) only. But what if Joe's group contains other users who aren't trusted enough to read FLAG? How can Sarah exclude the sinister Sam, for example?

With some complicated maneuvering, it's possible to accomplish these goals with self/group/public controls, but the more special cases you have, the more unwieldy this kind of file access becomes.

Access Control Lists

Access control lists (ACLs) are lists of users and groups, with their specific permissions. They offer a more flexible way of providing discretionary access control. ACLs are implemented differently on different systems. For example, in a UNIX-based trusted system that uses the UNIX security kernel developed by Atlanta-based SecureWare, you'd protect PAYROLL with ACLs in the form:

john.acct, r

jane.pay, rw

where:

• john and jane are login IDs of users who are allowed access to the PAYROLL file.
• acct and pay are group IDs of the users.
• r and w indicate the type of access allowed; r means that the user can only read PAYROLL, w that he or she can also change it.

If john is in the acct group, he can only read the file. If he belongs to any other group, by default he has no access. Similarly, if jane is in the pay group, she can read and write the file.

ACLs usually support wildcard characters that let you specify more general access to files. For example, you might specify:

<*.*, r>

to indicate that any user (*) in any group (*) can read (r) the file. You might specify:

<@.*, rw>

to indicate that only the owner (@) of the file can read (r) and modify (w) it.

In some systems, you can indicate that a particular user is specifically not allowed to access a file–for example, by specifying a null character or the word none or null) in place of an access character such as r or w.

sam.*,none  

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: August 13, 2019