13. Granting privileged actions

Task: allow user to perform an action that lies off standard user permissions:

• mount an external drive
• restart service
• edit system-wide service settings
• run certain application with super-user rights
• …

Setuid/Setgid

• Simple, verifiable mechanism

• Static (user always can perform an action if allowed)

• Actually limits control to allow/disallow running certain binary

Simple examples:

• -rws--x--x   1 root     root        56680 may 22 17:20 /bin/mount

  • Runs as root, so user can mount external drives

  • If there are restrictions, the program (mount) shall check them itself

• -rwx--s--x   1 root     shadow      10432 Jul  1  2018 /usr/bin/passwd

SETGID directory traversal

This is SETGID directory traversal example

• The hash of user password is stored to the /etc/tcb/<user>/shadow: -rw-r----- 1 george auth 80 сен 19  2018 /etc/tcb/george/shadow

• → Process with UID george can read and write

• The /etc/tcb/<user> directory is fully accessible for george user ¹: drwx--s--- 2 george auth 4096 сен 19  2018 /etc/tcb/george

• But /etc/tcb directory itself is not accessible by george or other users: drwx--x--- 62 root shadow 4096 мар 24 13:41 /etc/tcb

  • ⇒ root solely has full access

  • the only exception is process that belongs to shadow group: it can, knowing the certain file/directory name in /etc/tcb, gain access to that certain file/directory

  • ⇒ to gain an access to /etc/tcb/george/shadow the process shall belong to user george and to the 'shadow' group

  • …and that is the process run from /usr/bin/passwd!

Find all setgid binaries: find /*bin /usr/*bin -perm -2000 -ls

Su/Sudo

• su — execute process with the rights of another user

  • Mainly used for obtaining root shell (su -) or for temporarily drop root privileges

• sudo — execute process with the rights of another user, with

  • user/group/category selection
  • exact command specification (including command line arguments)
  • shell patterns
  • additional restrictions (environment filter, source or target user password requirement etc.)
  • …

Su/sudo ar just setuid wrappers, still allowing certain user to run certain command.

Policy kit

• polkit manual

• homepage

• Arch ilinux Wiki page (very informational as always)

Polkit is an application-level toolkit for defining and handling the policy that allows unprivileged processes to speak to privileged processes: It is a framework for centralizing the decision making process with respect to granting access to privileged operations for unprivileged applications.

• Built on the top of D-Bus

• Rules are programmed (non just configs)

• An authentication agent is used to make the user of a session prove that the user of the session really is the user (by authenticating as the user) or an administrative user (by authenticating as an administrator)

• A policy file specifies actions:

  • what kind of service is allowed
  • after what kind of authentication

  • Stored at /usr/share/polkit-1/actions

  • E. g.:

       1 <?xml version="1.0" encoding="UTF-8"?>
       2 <!DOCTYPE policyconfig PUBLIC
       3  "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
       4  "http://www.freedesktop.org/software/polkit/policyconfig-1.dtd">
       5 <policyconfig>
       6 
       7   <action id="org.archlinux.pkexec.gparted">
       8     <message>Authentication is required to run the GParted Partition Editor</message>
       9     <icon_name>gparted</icon_name>
      10     <defaults>
      11       <allow_any>auth_admin</allow_any>
      12       <allow_inactive>auth_admin</allow_inactive>
      13       <allow_active>auth_admin</allow_active>
      14     </defaults>
      15     <annotate key="org.freedesktop.policykit.exec.path">/usr/bin/gparted</annotate>
      16     <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
      17   </action>
      18 
      19 </policyconfig>
    

• A rule file is JavaScript-based snippet defining authorization rules

  • Pre-defined ones are stored at /usr/share/polkit-1/rules.d

  • Manually configured ones are stored at /etc/polkit-1/rules.d

  • E. g.:

       1 /* Allow users in admin group to run GParted without authentication */
       2 polkit.addRule(function(action, subject) {
       3     if (action.id == "org.archlinux.pkexec.gparted" &&
       4         subject.isInGroup("admin")) {
       5         return polkit.Result.YES;
       6     }
       7 });
    

• This rule file (/etc/polkit-1/rules.d/50-default.rules) defines how administrator authentication is performed:

     1  polkit.addAdminRule(function(action, subject) {
     2     return ["unix-group:wheel"];
     3 });
  

• A lot of rule examples here

See more on Arch linux page

Hardening and mandatory access mechanisms

Note: all these mechanisms are mechanisms of restriction, not of allowance

SELinux

SELinux is a security enhancement to Linux which allows users and administrators more control over access control.

• Works after POSIX ACL/DAC

• Can implement security schemes (scurity levels, user roles, categories atc)

• Can control a huge amount of system calls

• Provides extension of inodes, network packets etc. carrying security labels
• Rules are pre-binded in kernel to eliminate attack

AppArmor

AppArmor is Mandatory Access Control (MAC) like security system for Linux. AppArmor confines individual programs to a set of files, capabilities, network access and rlimits, collectively known as the AppArmor policy for the program, or simply as a profile. New or modified policy can be applied to the running system without a reboot.

• Works after POSIX ACL/DAC

• Operates with file paths instead of inodes and other low-lever objects

SMACK, SRBAC, …