Security
  Home arrow Security arrow Page 5 - Unix Host Security: Hacks 1-10
Dev Shed Forums 
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Smartphone Development  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Mobile Linux 
App Generation ROI 
IBM® developerWorks 
Forums Sitemap 
E-Commerce Hosting 
Linux Web Hosting 
Managed Hosting 
Small Business Hosting 
VPS Hosting 
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid 
Request Media Kit
Contact Us 
Site Map 
Privacy Policy 
Support 
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
Google.com  
SECURITY

Unix Host Security: Hacks 1-10
By: O'Reilly Media
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: starstarstarstarstar / 37
    2004-05-04


    Table of Contents:
  • Unix Host Security: Hacks 1-10
  • Secure Mount Points Hack #1
  • Scan for SUID and SGID Programs Hack #2
  • Scan For World- and Group-Writable Directories Hack #3
  • Create Flexible Permissions Hierarchies w/ith POSIX ACLs Hack #4
  • Protect Your Logs from Tampering Hack #5
  • Delegate Administrative Roles Hack #6
  • Automate Cryptographic Signature Verification Hack #7
  • Check for Listening Services Hack #8
  • Prevent Services from Binding to an Interface Hack #9
  • Restrict Services with Sandboxed Environments Hack #10

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      error-file:tidyout.log Del.ici.ous error-file:tidyout.log Digg
      error-file:tidyout.log Blink error-file:tidyout.log Simpy
      error-file:tidyout.log Google error-file:tidyout.log Spurl
      error-file:tidyout.log Y! MyWeb error-file:tidyout.log Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article

     
     
    ADVERTISEMENT


    Unix Host Security: Hacks 1-10 - Create Flexible Permissions Hierarchies w/ith POSIX ACLs Hack #4
    (Page 5 of 11 )


    When Unix mode-based permissions just aren’t enough, use an ACL.

    Most of the time, the traditional Unix file permission system fits the bill just fine. But in a highly collaborative environment with multiple people needing access to files, this scheme can become unwieldy. Access control lists, otherwise known as ACLs (pronounced to rhyme with “hackles”), are a feature that is relatively new to the Linux operating system, but has been available in FreeBSD and Solaris for some time. While ACLs do not inherently add “more security” to a system, they do reduce the complexity of managing permissions. ACLs provide new ways to apply file and directory permissions without resorting to the creation of unnecessary groups.

    ACLs are stored as extended attributes within the filesystem metadata. As the name implies, they allow you to define lists that either grant or deny access to a given file based on the criteria you provide. However, ACLs do not abandon the traditional permission system completely. ACLs may be specified for both users and groups and are still separated into the realms of read, write, and execute access. In addition, a control list may be defined for any user or group that does not correspond to any of the user or group ACLs, much like the “other” mode bits of a file. Access control lists also have what is called an ACL mask, which acts as a permission mask for all ACLs that specifically mention a user and a group. This is similar to a umask, but not quite the same. For instance, if you set the ACL mask to r--, any ACLs that pertain to a specific user or group and are looser in permissions (e.g., rw-) will effectively become r--. Directories also may contain a default ACL, which specifies the initial ACLs of files and subdirectories created within them. 

    To modify or remove ACLs, use the setfacl command. To modify an ACL, the -m option is used, followed by an ACL specification and a filename or list of filenames. You can delete an ACL by using the -x option and specifying an ACL or list of ACLs.

    There are three general forms of an ACL: one for users, another for groups, and one for others. Let’s look at them here:

    # User ACL
    u:[user]:<mode>
    # Group ACL
    g:[group]:<mode>
    # Other ACL
    o:<mode>

    Notice that in the user and group ACLs, the actual user and group names that the ACL applies to are optional. If these are omitted, it means that the ACL will apply to the base ACL, which is derived from the file’s mode bits. Thus, if you modify these, the mode bits will be modified and vice versa.

    See for yourself by creating a file and then modifying its base ACL:

    $ touch myfile
    $ ls -l myfile
    -rw-rw-r-- 1 andrew andrew 0 Oct 13 15:57 myfile
    $ setfacl -m u::---,g::---,o:--- myfile
    $ ls -l myfile
    ---------- 1 andrew andrew 0 Oct 13 15:57 myfile

    From this example, you can also see that multiple ACLs can be listed by separating them with commas.


    You can also specify ACLs for an arbitrary number of groups or users:

    $ touch foo
    $ setfacl -m u:jlope:rwx,g:wine:rwx ,o:--- foo
    $ getfacl foo
    # file: foo
    # owner: andrew
    # group: andrew
    user::rwuser:
    jlope:rwx
    group::---
    group:wine:rwx
    mask::rwx
    other::---

    Now if you changed the mask to r--, the ACLs for jlope and wine would effectively become r-- as well:

    $ setfacl -m m:r-- foo
    $ getfacl foo
    # file: foo
    # owner: andrew
    # group: andrew
    user::rwuser:
    jlope:rwx #effective:r--
    group::---
    group:wine:rwx #effective:r--
    mask::r--
    other::---

    As mentioned earlier, directories can have default ACLs that will automatically be applied to files that are created within the directory. Default ACLs are set by prepending a d: to the ACL that you want to set:

    $ mkdir mydir
    $ setfacl -m d:u:jlope:rwx mydir
    $ getfacl mydir
    # file: mydir
    # owner: andrew
    # group: andrew
    user::rwx
    group::---
    other::---
    default:user::rwx
    default:user:jlope:rwx
    default:group::---
    default:mask::rwx
    default:other::---

    $ touch mydir/bar
    $ getfacl mydir/bar
    # file: mydir/bar
    # owner: andrew
    # group: andrew
    user::rwuser:
    jlope:rwx       #effective:rwgroup::---
    mask::rwother::---

    As you may have noticed from the previous examples, you can list ACLs by using the getfacl command. This command is pretty straightforward and has only a few options. The most useful is the -R option, which allows you to list ACLs recursively and works very much like ls -R.

    Buy the book!If you've enjoyed what you've seen here, or to get more information, click on the "Buy the book!" graphic. Pick up a copy today!

    Visit the O'Reilly Network http://www.oreillynet.com for more online content.



     
     
    >>> More Security Articles          >>> More By O'Reilly Media
     

       

    SECURITY ARTICLES

    - Critical Microsoft Visual Studio Security Pa...
    - US Faces Tech Security Expert Deficit
    - LAN Reconnaissance
    - An Epilogue to Cryptography
    - A Sequel to Cryptography
    - An Introduction to Cryptography
    - Security Overview
    - Network Security Assessment
    - Firewalls
    - What’s behind the curtain? Part II
    - What’s behind the curtain? Part I
    - Vectors
    - PKI: Looking at the Risks
    - A Quick Look at Cross Site Scripting
    - PKI Architectures: How to Choose One


    Code Security
    Improve code security with Klocwork's static analysis and productivity



    © 2003-2010 by Developer Shed. All rights reserved. DS Cluster 12 Hosted by Hostway
    For more Enterprise Application Development news, visit eWeek