7:subdomain

From Linux Man Pages

Jump to: navigation, search

Contents

NAME

      AppArmor kernel enhancement to confine programs to a limited set of
      resources.

DESCRIPTION

      AppArmor (previously known as SubDomain) is a kernel enhancement to
      confine programs to a limited set of resources. AppArmor's unique secu-
      rity model is to bind access control attributes to programs rather than
      to users.
 
      AppArmor confinement is provided via profiles loaded into the kernel
      via subdomain_parser(8), typically through the /etc/init.d/subdomain
      SysV initscript, which is used like this:
 
              # /etc/init.d/subdomain start
              # /etc/init.d/subdomain stop
              # /etc/init.d/subdomain restart
              # /etc/init.d/subdomain kill
 
      AppArmor can operate in two modes: enforcement, and complain or learn-
      ing:
 
      o   enforcement -  Profiles loaded in enforcement mode will result in
          enforcement of the policy defined in the profile as well as report-
          ing policy violation attempts to syslogd.
 
      o   complain/learning - Profiles loaded in  "complain" mode will not
          enforce policy.  Instead, it reports policy violation attempts.
          This mode is convenient for developing profiles. To manage complain
          mode for individual profiles the utilities /usr/bin/complain and
          /usr/bin/enforce can be used.  These utilities take either the pro-
          gram name (if it's in your path or you specify the path), or the
          profile name (when the path is specified) as an argument.
 
      Profiles are traditionally stored in files in /etc/subdomain.d/ under
      filenames with the convention of replacing the / in pathnames with .
      (except for the root /) so profiles are easier to manage (e.g. the pro-
      file for the program /usr/sbin/sshd would be named usr.sbin.sshd).
 
      Profiles are applied to a process at exec(3) time (as seen through the
      execve(2) system call), but an already running process cannot be con-
      fined.  However, once a profile is loaded for a program, that program
      will be confined on the next exec(3).
 
      An AppArmor filesystem is available for listing the currently loaded
      profiles.  Use the following to mount the filesystem:
 
              # mkdir -p /subdomain
              # mount -tsubdomainfs none /subdomain
              $ cat /subdomain/profiles
              /usr/bin/mutt
              /usr/bin/gpg
                 ...
 
      Note that the admin must umount(8) this filesystem before the module
      will unload with rmmod(8).  The initscript /etc/init.d/subdomain will
      umount the filesystem when stopping AppArmor.
 
      The following line in /etc/fstab will make mounting the filesystem eas-
      ier:
 
              none    /subdomain      subdomainfs     noauto  0 0
 
      With this line in place, the filesystem can be simply mounted with:
 
              # mount /subdomain
 
      AppArmor also restricts the privileged operations a confined process
      may execute, even if the process is running as root. A confined process
      cannot call the following system calls:
 
              create_module(2) delete_module(2) init_module(2) ioperm(2)
              iopl(2) mount(2) umount(2) ptrace(2) reboot(2) setdomainname(2)
              sethostname(2) swapoff(2) swapon(2) sysctl(2)
 
      A confined process can not call mknod(2) to create character or block
      devices.

ERRORS

      When a confined process tries to access a file it does not have permis-
      sion to access, the kernel will report a message to klogd, similar to:
 
              SubDomain: REJECTING x access to /bin/bash (irssi(2667)
                profile /usr/local/bin/irssi active /usr/local/bin/irssi)
              SubDomain: REJECTING r access to /home/sarnold (mozilla-bin(3029)
                profile /usr/lib/mozilla-1.4/mozilla-bin active
                /usr/lib/mozilla-1.4/mozilla-bin)
              SubDomain: REJECTING rw access to /dev/pts/4 (sh(1721)
                profile /usr/bin/crontab active /usr/bin/crontab)
 
      The permissions requested by the process are immediately after REJECT-
      ING. The "name" and process id of the running program are reported, as
      well as the profile name and any "hat" that may be active. ("Name" is
      in quotes, because the process name is limited to 15 bytes; it is the
      same as reported through the Berkeley process accounting.) If no hat is
      active (see change_hat(2)) then the profile name is printed for
      "active".
 
      For confined processes running under a profile that has been loaded in
      complain mode, enforcement will not take place and the log messages
      reported to klogd will be of the form:
 
              SubDomain: PERMITTING r access to /root/.viminfo (vi(1272)
                      profile /bin/vim active /bin/vim)
              SubDomain: PERMITTING w access to /root/.viminfo.tmp (vi(1272)
                      profile /bin/vim active /bin/vim)
              SubDomain: PERMITTING wl access to /root/.viminfo (vi(1272)
                      profile /bin/vim active /bin/vim)
              SubDomain: PERMITTING rwl access to /root/.viminfo.tmp (vi(1272)
                      profile /bin/vim active /bin/vim)
              SubDomain: PERMITTING w access to /root/.viminfo (vi(1272)
                      profile /bin/vim active /bin/vim)

FILES

      /etc/init.d/subdomain
      /etc/subdomain.d/
      /usr/share/vim/vim61/syntax/subdomain.vim
      /usr/libexec/subdomain/

RELATED

      change_hat(2), subdomain.d(5), subdomain.conf(5), autodep(1), subdo-
      main.vim(5), unconfined(8), enforce(1).

CATEGORY

Personal tools