Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Linux ACL (Access Control Lists)

Linux was "ACL-retarded" OS for quite a long time which caused a lot of grief for administrators who use to work with ACLs on other OSes (Solaris used to have an excellent ACL implementation for a decade or so).  But the number of administrators who use ACL is very small and this deficiency actually matters much less that it looks on the first sight. Also this situation this recently changed. It is fully implemented in RHEL 5.2  and later for ext3 filesystem (and some other), as well as in Suse 10 SP2 and later. Previous situation when some utilities understood ACLs and some does not is corrected.

ACLs are additional sets of read/write/execute triplets (rwx) that can be added on to files, directories, devices, or any other file system objects on per user or per group basis. 

ACL are separate from Unix regular permissions. As they were added as an afterthought, the integration is not perfect: they are not displayed by default by commands such as ls ( ls just indicates whether they are present or not).  

While their popularity came from Windows, in essence, ACL can be viewed as an extension of a Unix group mechanism (multiple groups, each with a separate permissions set can be assigned to a file). In this case the fact of assigning access to a particular user can be viewed as an assignment of the particular permission set to a group with just one member (trivial group). 

As inability to assign files to multiple groups was a serious drawback of Unix from day 1, and ACL provides the capabilities for enhancing Unix  file security by enabling you to define file permissions for additional groups. For directories it also enables you to define default permissions.

It is important to understand that like regular permissions ACL behaves differently for files and directories (only directories have additional set of so called "default permissions").

The Linux  ACL facility is compliant with the POSIX 1003.6 specification.  Interoperation with other platforms is limited: until RHEL 5.2 Linux has weak implementation with many utilities (for example tar) which were "ACL-blind". Linux  implementation works with the NFS. Interoperability is limited both the NFS server and the client must be running Linux.

While ACL are file based they are essentially user-oriented: For each file you can define a list of additional users (pseudo-owners) and groups (pseudo-groups) that will have a certain level of access: read, write, or execute access permissions

ACLs grant "higher-level" access rights that have priority over regular file permissions.

Implementation is based on the concept of shadow inodes: when you create an ACL, the existing inode points to a newly allocated inode called a shadow inode. When a specific ACL entry is placed on the  ACL list, the shadow inode contains a pointer to a data block containing  the list of ACL entries. That permits utilities that does not understand ACLs work correctly with files that have ACLs set. In this case, for example when you are using gnu tar instead of Linux tar, they will strip all your ACL information.

Traditional Unix ls command is "ACL blind" and cannot display attributes,  but you can use the ls -l command to see which files or directories have an ACL entry. If a file has an ACL entry, a plus (+) sign appears at the end of the permission field.

There are two separate commands for working with ACLsy:

• setfacl permits setting a file's ACLs
• getfacl permits  reading them.

Running getfacl on a normal file provides mapping of regular permissions to ACL world:

% cd /usr/tmp
% touch foo
% ls -l foo
-rw-r--r--   1 pbg      staff          0 Jul 22 13:35 foo

% getfacl foo
# file: foo
# owner: pbg
# group: staff
user::rw-
group::r--              #effective:r--
mask:rwx
other:r--

The user, group and other information is a straightforward display of the permission bits for those fields.

It is also important to note that ACLs "stick" to a file during copy and rename operations that are performed using regular commands like cp and mv. To remove the ACL from a file use setfacl -d for each entry. When the last entry is removed, the "+" disappears from the ls listingy.

Setting ACLs for the user

To set an ACL for a file, use the command setfacl:

% setfacl -m user:jeff:rw- foo

% ls -l foo
-rw-r--r--+  1 pbg      staff          0 Jul 22 13:52 foo

% getfacl foo

# file: foo
# owner: pbg
# group: staff
user::rw-
user:jeff:rw-           #effective:r--
group::r--              #effective:r--
mask:r--
other:r--

The -m option tells setfacl that I want to modify the ACLs for the file. You can specify only those attributes that you need to change. It looks like man page statement "When using the -m option to modify a default ACL, you must specify a complete default ACL (user, group, other, mask, and any additional entries) the first time" is incorrect:

 -m acl_entries

Adds one or more new ACL entries to the file, and/or modifies one or more existing ACL entries on the file. If an entry already exists for a specified uid or gid, the specified permissions will replace the current permissions. If an entry does not exist for the specified uid or gid, an entry will be created. When using the -m option to modify a default ACL, you must specify a complete default ACL (user, group, other, mask, and any additional entries) the first time.

Use the -s option to set the entire mode, but then you must type in the user, group, and other access bits as well:

% setfacl -s user::rw-,group::r--,other:---,mask:rw-,user:jeff:rw- foo

To set general user, group, and other permissions, use the field::perms identifier. To set ACLs for individual users and groups, use the field:uid or gid:perms identifier.

But back to our previous example. Notice that the effective access for user Jeff is unchanged, he can still only read the file, not write to it. That's the result of the mask being applied to his permissions. To grant Jeff the access desired, I need to:

% setfacl -m mask:rw- foo
% getfacl foo

# file: foo
# owner: pbg
# group: staff
user::rw-
user:jeff:rw-           #effective:rw-
group::r--              #effective:r--
mask:rw-
other:r--

Now Jeff has read and write permissions to the file, while all others have only read access. Of note is the slight change in behavior of the ls command. Any file with specific ACL information is shown with a + at the end of the permission field. Unfortunately, find doesn't seem to have an option to find all files with ACL lists.

By now, your warning bells are probably going off.  A hacker, having broken into your system, could use the ACL facility to create back doors. These back doors are very difficult to spot -- only inspection of ls output will identify the target files.

ACL on Directories

Using the ACL facility on a directory adds some new twists. As well as setting an ACL for the directory, you can set a default ACL for the directory. This default ACL is used to set the ACL on every file created within the directory. The only way I managed to get directory ACLs to work was using the -s option with a very-long parameter string:

% setfacl -s user::rwx,group::rw-,mask:r--,other:rw-,default:user::rw-,\
default:group::r-x,default:mask:rwx,default:other:r-x bar

% ls -ld bar
drwxr--rw-+  2 pbg      staff        512 Jul 22 14:11 bar

% getfacl bar

# file: bar
# owner: pbg
# group: staff
user::rwx
group::rw-              #effective:r--
mask:r--
other:rw-
default:user::rw-
default:group::r-x
default:mask:rwx
default:other:r-x

Note:

I found that the FIRST time default ACLs are set, all of user, group, other and mask defaults must be set. This means that the first setfacl for a directory could be for instance:

$ setfacl -m d:u::rwx,d:o:---,d:g::---,d:m:rwx facltest/

Once these four default ACLs have been set, subsequent "normal" calls to setfacl can be made, such as:

$ setfacl -m default:user:myself:rwx facltest/

Now set a default ACL, and create a file in the directory:

% setfacl -m default:user:jeff:rwx bar

% getfacl bar

# file: bar
# owner: pbg
# group: staff
user::rwx
group::rw-              #effective:r--
mask:r--
other:rw-
default:user::rw-
default:user:jeff:rwx
default:group::r-x
default:mask:rwx
default:other:r-x
default:user::rw-
default:user:jeff:rwx
default:group::r-x
default:mask:rwx
default:other:r-x

% touch bar/test

% getfacl bar/test

# file: bar/test
# owner: pbg
# group: staff
user::rw-
user:jeff:rwx           #effective:r--
group::r--              #effective:r--
mask:r--
other:r--

There are several other aspects of ACLs, including deleting ACLs and using abbreviations and permission bit numbers (rather than symbols). This information is provided on the appropriate manual pages. You'll get a similar error if you try to use ACLs in a swapfs-based directory (such as /tmp). Finally, there's a "non-feature" of ACLs when used with  Linux tar.  Linux tar itself works well with files that have associated ACLs. Unfortunately, the tar file is not always readable under other OSes.  You might be better off using GNU tar instead.

You can set default ACL entries on a directory that apply to files subsequently created within the directories. Files created in a directory that has default ACL entries will have the same ACL entries as the directory. When you set default ACL entries for specific users and groups on a directory for the first time, you must also set default ACL entries for the owner, owner's group, others, and the mask.

•  d[efault]:u[ser]::<perm> Sets the default permissions for the owner of the directory.

•  d[efault]:g[roup]::<perm> Sets the default permissions for the owner's group.

•  d[efault]:o[ther]::<perm> Sets the default permissions for users other than the owner or members of the owner's group.

•  d[efault]:m[ask]::<perm> Sets the default ACL mask.

•  d[efault]:u[ser]:<UID>:<perm> Sets the default permissions for a specific user.

•  d[efault]:g[roup]:<GID>:<perm> Sets the default permissions for a specific group.

Old News ;-)

InformIT Managing Storage in Red Hat Enterprise Linux 5 Using Access Control Lists

[Jul  1, 2008] pyxattr 0.4.0 by Iustin

About: pyxattr is a Python extension module wrapper for libattr, which can be used to query, list, add, and remove extended attributes from files and directories.

Changes: A new set of functions with a different, namespace-aware API has been added. The license has been changed to LGPL 2.1.

[Jun 18, 2008]  Smart ACL management with Eiciel By Shashank Sharma

Linux.com

The traditional file permission model, where read, write, and execute permissions are set on each file for the user, group, and others (UGO) has one drawback: It can't be used to define per-user or per-group permissions. For that, you need to employ access control lists (ACL). Eiciel is a graphical tool that integrates with the Nautilus file manager and allows for easy ACL management.

The UGO model lets you associate only one group with a file. If you try to define read permissions on a file for user Charlie and read and write permissions for user Alexia, and Charlie and Alexia belong to different groups, you'll see what I mean. With ACLs, you can specify elaborate permissions for multiple users and groups.

Although Eiciel is a GNOME tool, you can run it on KDE as well if you have the necessary GNOME libraries installed. ACL supports is natively available in the 2.6 kernel, and ext2, ext3, XFS, JFS, and ReiserFS filesystems are ACL-capable.

You can install Eiciel from official software repositories of your distribution using apt-get or yum. Once installed, Eiciel is available as a standalone application or as a Nautilus extension, but you'll have to restart Nautilus before you can take advantage of the extension. After restarting Nautilus with the killall nautilus command, to define ACL entries, right-click on a file and select Properties, then click the Access Control List tab.

ACLs too rely on the traditional read, write, and execute permissions defined for each user and group. To define ACLs for users and groups, add them to the access control list by selecting them from the bottom half of the window and clicking Add. You can then define permissions for each of the users or groups you just added. The user and groups are listed under Entry with three check-boxes corresponding to read, write, and execute. You can thus define any concoction of permissions for the users and groups of your choice.

[Jun  1, 2008] Linux ACLs by Nicholas Kirsch

www.samag.com

Why use Access Control Lists (ACLs)? Aren't traditional Unix file permissions enough for any situation? Consider, for example, a semester-long software engineering course in which 30 students work in three-member teams on two projects. With traditional Unix permissions, each team/project combination would require a group, because all the team members must be able to collaborate, but teams must be isolated. Additionally, the professor needs access to project files for grading and for remote assistance. With this setup, the systems administrator would need to create 20 unique groups for each semester. If there were four such courses, there would be 80 groups; and if there were four projects, there would be 160 groups. With standard Unix permissions, the students cannot administer the groups themselves and the permissions are not flexible enough to allow the students to share their files with only members of their teams. This obviously becomes a management nightmare and a lot of work for the administrator.

Another example in which Unix permissions are inadequate is a mail server at a typical ISP. The ISP has a mail process that runs as user mail and file system quotas are enforced on both individuals (users) and organizations (groups). The mail process must be able to read and write the spool files, but not allow other users to read those same files (we assume no security flaws in the mail process). The admin is forced to make the mail spool files belong to the mail group while the files themselves are owned by the specific users. The admin can only (automatically) enforce quotas for users and not groups in this scenario, which is a potential loss of revenue for the ISP, who would prefer the more stringent of the group/user quotas to be enforced.

Linux supports POSIX ACLs in the stock 2.6 kernel. Linux implements ACLs based on two POSIX drafts -- 1003.1e and 1003.2c -- even though official sponsorship of those drafts was withdrawn in 1998. FreeBSD and Solaris also have almost identical ACL semantics.

POSIX_ACLs_shells

Minimizing Host Exploitation by Reducing Access to "Popular" Executables by Use of POSIX ACL's Limited Publishing: 02/25/2003

Overview

This document provides a solution to reduce the effectiveness of most buffer overrun exploits by preventing the effective user id of the compromised process from accessing a shell or other "popular" process from which to pursue his/her attack. This is an extremely simple technique utilizing POSIX ACL's (Access Control Lists) and does not introduce any additional load on a modern OS.

Credits

Concept: Kristofer Spinka (kspinka@style.net) Proof of Concept: TBD

Concept

This works as is on Linux and Linux, however RedHat temporarily removed support for getxattr()/setxattr() which actually implements "setfacl -m"; I think they had a stability problem. It works as expected on Linux, but of course, it's Linux. If you encounter non-standard limitations on other platforms, please provide feedback.

1. First make a dummy shell for testing and verification

    vi shell.c:
   -----------
   #include <unistd.h>
   
   int
   main(int argc, char *argv[])
   {
         write(1, "shell started!\n", 15);
         return 1;
   }
   -----------
       gcc -o shell shell.c
   

2. Create a "web server user" for testing. This is only temporary, we will remove it after testing.

        become root
        groupadd -g 57470 facltest
        useradd -c "setfacl test account" -d /tmp/facltest -g facltest -s /bin/bash -m -u 57470 facltest
        passwd facltest (set a password for the account)
        drop root
        

3. Execute setfacl -m u:facltest:--- shell

   This will remove all permissions for user "nobody" from the file "shell".
    

4. su - facltest attempt to execute "shell" created in step 1
    
5. Cleanup test environment. userdel -r facltest groupdel facltest
    
6. Apply facl's to all shells or other "popular" executables on your system for the account used to run network servies one by one, for example:

        setfacl -m u:nobody:--- /bin/ash
        setfacl -m u:nobody:--- /bin/bash
        setfacl -m u:nobody:--- /bin/csh
        setfacl -m u:nobody:--- /bin/sh
        setfacl -m u:nobody:--- /usr/bin/es
        setfacl -m u:nobody:--- /usr/bin/ksh
        setfacl -m u:nobody:--- /bin/ksh
        setfacl -m u:nobody:--- /usr/bin/rc
        setfacl -m u:nobody:--- /usr/bin/tcsh
        setfacl -m u:nobody:--- /bin/tcsh
        setfacl -m u:nobody:--- /usr/bin/zsh
        setfacl -m u:nobody:--- /bin/sash
        setfacl -m u:nobody:--- /bin/zsh
        setfacl -m u:nobody:--- /usr/bin/esh
        setfacl -m u:nobody:--- /bin/dash
   

   You should repeat this for *all* user accounts that run your network services, for example, the user account that httpd runs as, the user account named runs as, the user account sendmail runs as, etc.

ACL Interactions With Microsoft

Microsoft Windows has its own version of access control lists. When PC users Citrix MetaFrame users write files from Windows to the BCG storage server via samba, the Microsoft ACL associated with a file is translated to a Unix ACL. Sometimes this is done only by setting the standard Unix permissions.

In other cases, the Linux ACL system described above is used. An ACL is usually set when a file's  "Properties->Security"  menu is modified. For example, if you grant another user access to a file through Windows, you'll find a '+' sign on the permissions when you list it from Linux. You can remove the ACL with  rmacl  command described above, but then the user to whom you granted access from Windows will no longer be able to access the file.

Recommended Links

---

In case of broken links please try to use Google search. If you find the page please notify us about new location

• HOWTO Use filesystem ACLs - Gentoo Linux Wiki

• POSIX Access Control Lists on Linux

• [PDF] Access Control Lists in Linux
• Using ACLs with Fedora Core 2
• Fine-Tuning Linux Administration with ACLs
• Introduction to Linux Capabilities and ACL's

• Using Linux ACLs

• DecisionACL - Manage and Build Access Control Lists

• POSIX Access Control Lists on Linux

• Linux Advanced System Administrator's Guide, Second Edition Understanding System Security

• GNU cfengine - Linux ACLs

• POSIX ACLs in Linux

Modification of ls to display ACL "in-line"

something or another… » lsacl

The classical user/group/everyone file permissions that the UNIX world has been used to the last 30 years, is pretty much an assumed. Nowadays, however, many UNIX implementations allow for granular file access control lists. Most UNIX administrator’s still avoid them because they are not as apparent to them when doing a file listing.

I decided to be different. I wrote a tool to enhance the standard “ls” command into displaying file ACL’s.

Etc

Linux ACLs

Under Linux, the ACL type can be one of the following:

        user
        group
        mask
        other

For directories only

default_user
default_group
default_mask
default_other

A user or group can be specified to the user, group, default_user and default_group types. Linux ACL permissions are the normal UNIX permissions bits `rwx', where:

   r - Grants read privileges.
        w - Grants write privileges.
        x - Grants execute privileges.