| MJesus | welcome to the 8ª session of UMeet'2005.
| MJesus | the last lecture for today will be talk by Russell Coker
| MJesus | From Australia, Mr Coker will talk about "Present of SELinux"
| MJesus | hi is working working on SE Linux since mid 2001 and working for Red
Hat since 2003.
| MJesus | As you kow, this channel will be moderadet until the end of the lecture.
| MJesus | If you have some questions or comments about, please, write it in the
channel #qc.
| MJesus | En el canal #redes habra voluntarios traduciendo a español ( In #redes
spanish translation)
| MJesus | All for you Russell !
| russell | Good morning/evening everyone.
| russell | SE Linux is a system for Mandatory Access Control (MAC). MAC
means that the OS (IE the security policy determined by the sys-admin) has
control over what access is granted. Unix permissions are known as
Discretionary Access Control (DAC) because an application can grant whatever
access it wants to it's own resources (EG create a mode 777 file in /tmp).
| russell | For more information on MAC see http://en.wikipedia.org/wiki/Man
datory_access_control
| russell | To fulfill Linus' requirements the LSM project was begun. During
development of LSM the modules supported were DTE, OpenWall, SE Linux, and
sometimes LIDS. Later support for OpenWall, DTE, and LIDS was dropped as the
code wasn't maintained thus leaving SE Linux as the only significant security
module based on LSM. In kernel 2.6.2 LSM was merged into the kernel.org tree
and so was SE Linux. Since then SE Linux has been a standard pa
| russell | The core technology of SE Linux is the "domain type
| russell | model.
| russell | SE Linux controls all access to the system. I have on many
occasions run SE Linux "play machines" with an open root password. See
http://www.coker.com.au/selinux/play.html for details. Please do not run DOS
attacks!
| russell | The LSM interface forces SE Linux to only apply restrictive
access controls. It was one of the design criteria used for LSM that derives from
the fact that LSM hooks are called after Unix permission checks.
| russell | Also SE Linux permits auditing operations, the policy determines
which operations are audited, by default every operation that is denied is audited
and no operations that are permitted are audited. If the SE Linux policy instructs
that an operation is to be audited but Unix permissions prevent it then the SE
Linux code won't see the attempt and therefore nothing will be audited.
| russell | The AUDIT layer (recently added to the kernel.org kernels) is
designed for serious auditing. SE Linux auditing is only designed for auditing
events directly related to SE Linux not the rest of the system. The Linux auditing
sub-system allows security-critical applications (such as login, pam, cron) to
audit their operations.
| russell | There are three main problems with Unix security. One is that
being a DAC system programs can grant inappropriate access to their resources.
One example is a Java IDE that put all it's working files under /tmp with mode 777
and thus couldn't be used on a multi-user system (there are many other examples
that are more subtle and might be missed by a typical sys-admin).
| russell | This diagram shows the domain transitions used in booting a
system: http://www.coker.com.au/selinux/talks/rh-2005/domains.png
| russell | Initially all processes run in domain kernel_t. /sbin/init is
responsible for loading the policy, after the policy is loaded it re-exec's itself.
When a process is executed on a SE Linux system the kernel checks the policy
database to determine the necessary action. It performs a check based on the
domain of the calling code (in this case kernel_t) and the type of the file to be
executed (in this case init_exec_t), the policy says t
| russell | The policy for this is domain_auto_trans(kernel_t, init_exec_t,
init_t). There are other automatic transitions to go from init_t to initrc_t, and from
initrc_t to the domains for daemons.
| russell | A SE Linux security context is comprised of three parts
identity:role:type (where type means domain for the context of a process and the
role is always object_r for a file on disk).
| russell | The diagram at http://www.coker.com.au/selinux/talks/rh-2005/con
texts.png shows how contexts are determined for user processes. The identity is
based on the account name of the user (in the past it was either the exact Unix
account name or "user_u" for users who's account was not compiled into the
policy - now we have a mapping layer to allow arbitrary mappings that the
administrator requests from Unix account name to SE Linux identit
| russell | The role is determined by the identity, the policy determines
which roles an identity may use. Therefore when the administrator determines
which identity a user gets that indirectly determines which role(s) they get. The
role limits which domains may be entered by processes derived from the user's
session. Therefore the identity limits what access may be granted to programs in
the user's session.
| russell | The diagram shows two identities "root" and "bofh". The "root"
identity is only permitted the role "user_r", this is similar to the configuration on
my SE Linux play machine. The "bofh" identity is permitted "user_r" and
"sysadm_r". Therefore the user "bofh" may login as a regular user or as the
administrator.
| russell | The user_r role is only permitted the user_t domain (and other
similar domains) while the sysadm_r role is permitted the sysadm_t domain
which allows full access to the system.
| russell | Note that as SE Linux access control is performed after Unix
access control a process must have both sysadm_t domain and UID 0 to have full
administrative access.
| russell | In the SE Linux model there is no required hierarchy of domains.
It is not neceessary that any one domain have all access to the system, in the
"strict" policy there is no single domain that has full access. However a hierarchy
suits the needs of administrators, so the sysadm_t domain has almost all access -
not because SE Linux requires it but because the users do. The policy can be
changed according to the needs of the administrat
| russell | There are currently three policies. "strict" which restricts
everything to minimal privs, "targeted" which restricts daemons known to be at
risk of attack but doesn't restrict all daemons and doesn't restrict user sessions,
and "mls" which is based on "strict" but adds Multi-Level Security support.
| russell | See the following URL for background information on MLS:
http://www.cs.stthomas.edu/faculty/resmith/r/mls/index.html
| russell | In released implementations of SE Linux (such as Fedora Core 4
and Red Hat Enterprise Linux 4) the policy is written in the M4 macro language.
The M4 processor compiles the macros into a single policy file, this is then
compiled by the SE Linux policy compilation program into a file that can be
loaded into the kernel.
| russell | The value of a boolean may determine the access to change
booleans, so for secure-level functionality when the administrator changes such
a boolean all access to change it back is removed.
| russell | In SE Linux the Domain-Type model is used for protecting system
integrity and MLS is used for protecting secrecy of data. The "strict" policy uses
the DT model to protect some secret data (such as /etc/shadow), but doesn't
nearly do as much as MLS.
| russell | It's expected that MLS will not be used by home users or many
commercial organizations, it's difficult to use and most organizations don't need
it. It's designed for military organizations.
| russell | The SE Linux kernel interface for loading policy, changing
booleans, and other system operations is the selinuxfs file system mounted on
/selinux. For example to load a policy you just have to write the policy file to
/selinux/load.
| russell | For a process to control it's own SE Linux use (the context of a
chile process or of a file to be created) there are files under /proc/self/attr. For
every process it's context is under /proc/X/attr/current (this file is used by "ps"
and similar programs).
| russell | For persistent file systems (such as ext3) full support of SE Linux
requires supporting the XATTR interface for file labels. The xattr named
"security.selinux" is used to store the security context of the file. This means that
the security context is assigned to the file Inode and if the file (or the directory
containing it) is renamed then the access does not change.
| russell | Tools such as "ls", "cp", and "mv" have been patched to deal
with this. It's also possible to use the xattr toole, for example "getfattr -n
security.selinux file" will show the SE Linux security context of a file.
| russell | One thing to note about SE Linux is that it is fully configured by
policy. The administrator can edit plain text files and then recompile and load the
policy to change their system policy. Some other MAC systems have had the
policy compiled into applications thus forcing application code changes to
change the system security policy (this is particularly annoying when the
applications are secret-source and the administrator is not per
| russell | SE Linux has a number of modified programs for a full
implementation. For example /bin/login, sshd, cron, and XDM programs are
modified to grant the appropriate security context to programs launched for a
user. It would be possible to run a SE Linux system without such modified
programs, but this would require a less restrictive policy and therefore give less
security.
| russell | For further information see the NSA web site http://www.nsa.gov/s
elinux/ and my web site http://www.coker.com.au/selinux/
| russell | Questions?
| russell | Incidentally my play machine is running right now if you want to
login to it: http://www.coker.com.au/selinux/play.html
| MJesus | thanks russell!
| garoeda | thank you very much for this talk russell !
thanks russell
| garoeda | if you have any questions related to this talk, now is your time :)
| MJesus | "SE Linux has a number of modified programs for a full
implementation."...the mostly of the program are modified ?
| russell | MJesus: What do you mean by "the mostly of the program"? The
modified programs are the ones I listed, the programs to display contexts (ps, ls),
the programs to set the contexts of files (cp, mv, and logrotate).
| russell | MJesus: There are probably some modified programs I forgot to
mention, but those are the most important ones.
| MJesus | ok, thanks !
| russell | Arador: Debian work continues. The next release should have
full support, hopefully including the installer.
| Arador | nice
| MJesus | is selinux related with openwall ?
| MJesus | of solar designer ?
| russell | MJesus: No. SE Linux does everything different.
| russell | MJesus: OpenWall has as it's first and most notable feature a
non-executable stack. This functionality is provided by Exec-Sheild and Pax,
both of which work with SE Linux and for both of them SE Linux controls the way
that they work.
| russell | MJesus: OpenWall also has some other features such as
preventing the creation of symbolic links to files that you don't own. The SE
Linux solution to that is to have daemons denied access to symlinks created by
unprivileged users by default which prevents many race conditions related to
symlinks in /tmp.
| russell | MJesus: The only connection between OpenWall and SE Linux is
that for a while they were both LSM modules, then the LSM module of OpenWall
wasn't maintained and last time I checked it had been removed from the
kernel.org source.
| garoeda | I think we can close this evening's session. In the name of
Umeet I would like to thank Russell Coker for his talk and the audience for
listening.
| russell | Thanks for the opportunity to speak.
| russell | For further discussion you can visit #selinux on freenode.
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
|
|---|
