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
LSM
* framework for security enhancements to Linux
* Restrictive controls only
* SELiunux is based on LSM and the patch is distributed from
http://lsm.immunix.org/
* 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
engineering"
* 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,
etc.)
* Having one domain would give the same result as a non-SE system
o the more domains, the more detailed control you have over
security
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
Identities
* 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
domains
Debianization
* 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
system_u:system_r:dpkg_t
* 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"
Q/A
* 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
linux-security-moduleat_private
http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Sat Jun 29 2002 - 12:07:44 PDT