OLS: Packaging NSA SELinux for Debian

From: Crispin Cowan (crispinat_private)
Date: Sat Jun 29 2002 - 12:06:03 PDT

  • Next message: jmjonesat_private: "Re: OLS Bof info"

    Packaging NSA SELinux for Debian
    Russel Cocker
    What is SE Linux?
        * a system for MAC based on LSM
        * Uses features of RBAC and type enforcement
        * tracks user identity through all ops (su, role and domain
          transition) and uses it to lmmit the avail roles
        * removes the power of root, I gave away the root password to my
          Cobalt Qube and on one could cause any damage
        * SE is very powerful, in many ways a superset of the functionality
          of other MAC systems - can impl other MAC systems in SE policy
        * framework for security enhancements to Linux
        * Restrictive controls only
        * SELiunux is based on LSM and the patch is distributed from
        * LSM patch also includes a port of the OpenWall kernel patch from
          http://www.openwall.com/ but they are mostly mutually exclusive
    What is wrong with DAC?
        * programs have full control over the access given to files they create
        * therefore no protection against malicious software or "social
        * example: trick a user into running a program, it can listen to a
          TCP prot that's not firewalled, accept remote logins, and allow
          full control of their account
        * When program A runs program B both programs *must* have access to
          every file each of them needs with the exception of SUID programs
          (in which case program B gets full access but program A does not)
    Other Problems of "Unix Security"
        * too coarse grained (root v.s non-root gives boolean security model
          for many cases)
        * consequently many system programs are forced to run with full
          administrative access
              o BIND needs acces to port 53 and gets acces to write any file
                in the system as well
    What does MAC Provide
        * strong separation of security domains
        * fine grained control over resources
        * ...
    Domain Type Access Control
        * Every process has a domain, every object has a type
        * Domain is changed at process execution, either auto through policy
          or through code in "login" type programs
        * Different domains have different access rights, no domain is
          necessarily a superset of other domains
        * The user can re-authenticate at any time to change domains, or the
          domain can be changed aut by process execution according to policy.
        * Each object (file, network port/interface, etc) has a type
        * Policy rules determine what access every domain has to each type
        * Policy rules control interaction between domains (signals, pipes,
        * Having one domain would give the same result as a non-SE system
              o the more domains, the more detailed control you have over
              o and the more work to set it up
    Role Based Access Control
        * Each role has a list of domains that may exist in it
        * at login time, the session is changed, also the newrole program
          may be used to change roles (comparable to an su operation)
        * a role doesn't often change (unlike the domain which regularly
          changes automatically without the user noticing)
        * the role determines which domains are valid
        * User can only change roles by re-authenicating with newrole or
          run_init in the current utility programs
              o this can be changed
        * Identity is usulally the Unix account name when the details of an
          account have been compiled into the policy, or user_u otherwise
              o a login program issue that can be changed in the libraries
        * identity controls the available roles which controls the available
        * Made dpkg (Debian package management tool) set the correct
          security context of files after file install butbefore postinst script
        * this req. a patch tot the setifles program
              o setfiles sets the SE context of files and was initially
                designed only for installing new systems
              o I patched it to take a list fo files on stdin, and then
                patched dpkg to run a script to apply the contexts
              o The setfiles patch is in SELinux now, the dpkg patch is
                still pending
        * When installing packages, wrapper se_dpkg when run from sysadm_t
          re-authenticates the user (as does run_init) and runs dpkg as
        * Needs to be run as system_u and system_r role to allow an
          automatic domain transition to result in init scripts being run as
          system_u:system_r:initrc_t (for daemons that are started in postinst)
        * Domain transition from dpkg_t to initrc_t when executing scripts
          of etc_t for daemon startup
        * Developed scripts to manage policy files, manage additions of new
          policy and mering changes, installing a new policy package should
          not make any changes to the installed policy without asking the
          user first!
    Policy Aims
        * Main sample policy gives minimal privs to every daemon (a separate
          domain for each daemon) and creates separate user domains for
          programs such as Email client, GPG, X, etc (haven't yet written
          the domain for email)
        * have to support all the programs that are part of a standard
          Debian installation  plus all standard cron jobs
    Worki that need sto be done
        * writing much more sample policy (huge amout of work)
        * change the remaining login type programs (xdm, kdm, etc) to chagne
          the domain of the user's process and to change the type of any
          device files
        * sample policy for chroot env. similar to GR Security
        * sample policy similar to LOMAC with tow domains for pivileged and
          unprivileged processes
        * sample policy snippets for "no way out"
        * On July 10 I will put another SELinux play machine on the net, go
          to irc.openprojects.net#selinux for details
        * I will be in Ottawa until July 2 and in Toronto until July 8 if
          anyone needs a meeting
        * http://www.coker.com.au  links to everything
        * http://www.coker.com.au/selinux/ SE Linux Debian packages, etc.
        * http://www.coker.com.au/~russell/ My home page
        * Q: can you runa  daemon without using the startup daemon
        * A: yes, but the shipping packages do not permit that. Wants to
          facilitate some kind of automatic domain transition.
        * Q: how about a web browser domain?
        * A: of course! But it takes time; feel free to help.
        * Q: why did the NSA choose MAC instead of ACLs
        * A: [Russ loans the questioner a clue much more politely than
          Crispin would have :]
        * Q: [Alan Cox]: do something to protect Bash history, because
          people consistently type their password into a bash prompt by mistake
        * A: Yes ...
        * Announce: If you are a developer, and you have some special secret
          data, then *please* create a separate executable to access that
          data. This enables systems like SELinux [and SubDomain: Crispin]
          to manage privileged access to the secret data.
        * Q: [Alan Cox] should dpkg create files in a super-secure mode to
          prevent install-time tampering, and some stuff about /tmp handling
          that I couldn't hear
        * A: couldn't hear Russ' answer either
    Crispin Cowan, Ph.D.
    Chief Scientist, WireX Communications, Inc. http://wirex.com/~crispin/
    Security Hardened Linux Distribution:       http://immunix.org
    Available for purchase: http://wirex.com/Products/Immunix/purchase.html
    linux-security-module mailing list

    This archive was generated by hypermail 2b30 : Sat Jun 29 2002 - 12:07:44 PDT