[ISN] Linux File Permission Confusion

From: InfoSec News (isnat_private)
Date: Fri Apr 18 2003 - 04:36:51 PDT

  • Next message: InfoSec News: "[ISN] Secunia Weekly Summary"

    +------------------------------------------------------------------+
    |  Linux Security: Tips, Tricks, and Hackery                       |
    |  Published by Onsight, Inc.                                      |
    |                                                                  |
    |  17-April-2003                                                   |
    |  http://www.hackinglinuxexposed.com/articles/20030417.html       |
    +------------------------------------------------------------------+
    
    This issue sponsored by Linuxfest Northwest 2003, Bellingham, WA,
    April 26
    
    LFNW is a showcase for what Northwest Linux users are doing with
    Linux and open source software. It's a place for Linux enthusiasts to
    get together to share their passion for what good software can do.
    This year's fest will include boatloads of demonstrations, tutorials,
    and lectures by gurus such as John "Mad Dog" Hall, Randal Schwartz,
    and your very own Linux Security geek, Brian Hatch.
    
    Admission is free. For more information, see www.linuxnorthwest.com.
    Come join the fun!
    
    --------------------------------------------------------------------
    
    Linux File Permission Confusion
    By Brian Hatch
    
    Summary: File permissions, the most basic form of security control
    that exists on Unix-like systems, is still misunderstood by many.
    
    Linux has many different level of security. The kernel is protected
    from user processes; a user can only affect his own processes; and
    user processes are protected from each other. This security model
    requires that you must specifically allow users and processes to
    interact, otherwise there is no avenue for interaction and thus no
    avenue for attack.
    
    The most basic security feature of any unix-like operating system is
    file permissions. However, even though this is the most simple line
    of defence, it is still misunderstood by many. Frequently, in an
    administrator perspective, I need to re-teach users how file perms
    work when they find that other users can access files they thought
    were unaccessible. Worse yet is when poor file permissions are used
    as part of an attack that should never have had a chance.
    
    File permissions are those letters you see at the beginning of ls -l
    output:
    
     $ ls -l
     drwxrwxrwx    1 reegen   reegen      4096 Jan 22 10:05 dropbox
     drwx------    1 reegen   reegen      4096 Dec  6  8:50 private_logs
     -rw-r--r--    1 reegen   reegen      9663 Oct  8 16:03 public
     -rw-------    1 reegen   reegen      8925 Jan 12 11:17 secret
    
    The first part of the output has 10 characters, which can be broken
    up as follows (excuse the ASCII art....)
    
      d   rwx   rwx   rwx
      |    |     |     |
      |    |     |     \-> "Other" permissions
      |    |     |
      |    |     \-> "Group" permissions
      |    |
      |    \-> "User" permissions
      |
      \-> Type of file
    
    The first character says what kind of file this is. (d==directory, l=
    =symlink, p==pipe, s==socket, etc). The next three groups define the
    permissions of this file. An "r" means "allow read access", a "w"
    means "allow write access", and "x" means "allow execute access.
    
    On a normal file ("-" in the type-of-file field) "read" and "write"
    are pretty self explanatory. "Execute" means that this file can be
    executed as a program.[1]. So if the file were a shell script or
    valid compiled executable (ELF format, etc) named program_name, you
    could run ./program_name or, if this directory were in your path,
    just program_name. Without the execute bit, you'd need to type sh
    program_name for a shell script, perl program_name for a perl script,
    etc.[2]
    
    The kernel decides if you have read/write/execute access based on
    these rwx bits. Say you want to read a file -- what logic does the
    kernel use to decide if you should be granted read access? Test your
    intuition with the following examples:
    
     $ id
     uid=1000(doug) gid=1000(doug) groups=1000(doug),1001(web)
    
     $ ls -l foo.html
     -rw-r-----    1 www-data  web         9663 Oct  8 16:03 foo.html
     
    
    Following this logic, we'd all agree that doug can read this file,
    because he's part of the group web, which has read access. However
    how about this situation:
    
     $ id
     uid=1000(doug) gid=1000(doug) groups=1000(doug),1001(web)
    
     $ ls -l bar.html
     -rw----r--    1 www-data  web        19838 Sep 17  4:22 bar.html
     
    
    Most people's intuition would say sure, doug can read this file,
    since the read bit is set for other. This is not the case!
    
    Standard file permissions come in three flavours: user, group, and
    other. Many people think that if any option is satisfied, then access
    is granted. In reality, the kernel checks only the most appropriate -
    it does not "check all of them, falling through when a particular
    test fails"!
    
    So, to be explicit, here is how you can think of the file permission
    logic, using read access as an example:
    
     1. If the user is the owner of the file, see if the owner read bit
        (400) is set. If not, tough luck. Do no other tests.
       
     2. If the user is a member of the group that owns the file see if
        the group read bit (040) is set. If not, tough luck. Do no other
        tests.
       
     3. If the user is not the owner of the file nor a member of the
        group that owns the file, see if the other read bit (004) is set.
        If not, tough luck. Do no other tests.
    
    The distinction is an important one. You could create a file that you
    own that is readable by group and other, but not by you[3]. Yes, this
    seems somewhat counterintuitive.
    
    We are frequently put in a position where we want to give only
    certain users access to a directory or files. We put them in a
    special group, and tailor the group permissions of the files/
    directories to allow them this special access. Say we wanted to have
    the compiler only available to developers, we may do the following:
    
      # ls -l /usr/bin/gcc
      -rwxr-xr-x    1 root     root        74088 Sep 23 15:13 /usr/bin/gcc
    
      # addgroup devel
      # chgrp devel /usr/bin/gcc
      # ls -l /usr/bin/gcc
      -rwxr-xr-x    1 root     devel       74088 Sep 23 15:13 /usr/bin/gcc
    
      # chmod o-rx /usr/bin/gcc
      # ls -l /usr/bin/gcc
      -rwxr-x---    1 root     devel       74088 Sep 23 15:13 /usr/bin/gcc
    
    Now only root and the users in the devel group can run gcc. This is
    the kind of group modifications we most frequently make. But what
    happens if we want to have almost everyone able to use gcc except for
    a few troublemakers? We can add everyone to this group, but that's a
    management pain. But remember - the kernel only checks the best match
    from user/group/other, not all of them. So instead, we do things the
    other way around:
    
      # ls -l /usr/bin/gcc
      -rwxr-xr-x    1 root     root        74088 Sep 23 15:13 /usr/bin/gcc
    
      # addgroup jerks
      # chgrp jerks /usr/bin/gcc
      # ls -l /usr/bin/gcc
      -rwxr-xr-x    1 root     jerks       74088 Sep 23 15:13 /usr/bin/gcc
    
      # chmod g-rx /usr/bin/gcc
      # ls -l /usr/bin/gcc
      -rwx---r-x    1 root     jerks       74088 Sep 23 15:13 /usr/bin/gcc
    
    What do we have now? gcc can only be run by root, and anyone not in
    the group jerks. We can maintain the (hopefully short) list of jerks
    much more easily than adding everyone to the devel group. The
    management nightmare is over.
    
    Next week we'll cover the finer points of directory permissions,
    after which we'll get back to more interesting aspects of Linux
    Security.
    
    NOTES:
    
    [1] Of course, if the file isn't an executable program, shell script,
    or other recognisable form, Linux will stick it's tongue out at you.
    
    [2] Even compiled executables can often be run without the execute
    bit, such as using /lib/ld-linux.so.2 program_name. You loose the
    ability to run setuid/setgid programs with their extra permissions if
    you use any of these methods.
    
    [3] Of course you could always chmod it since you own it.
    
                                -------------                            
    Brian Hatch is Chief Hacker at Onsight, Inc and author of Hacking
    Linux Exposed and Building Linux VPNs. Several years ago he ran
    "chown bree /dev/heart" and has been happy ever since. Brian can be
    reached at brianat_private
    
    --------------------------------------------------------------------
    This newsletter is distributed by Onsight, Inc.
    
    The list is managed with MailMan (http://www.list.org). You can
    subscribe, unsubscribe, or change your password by visiting
    http://lists.onsight.com/ or by sending email to
    linux_security-requestat_private
    
    Archives of this and previous newsletters are available at
    http://www.hackinglinuxexposed.com/articles/
    
    --------------------------------------------------------------------
    
    Copyright 2003, Brian Hatch.
    
    
    
    -
    ISN is currently hosted by Attrition.org
    
    To unsubscribe email majordomoat_private with 'unsubscribe isn'
    in the BODY of the mail.
    



    This archive was generated by hypermail 2b30 : Fri Apr 18 2003 - 07:59:39 PDT