* Re: trusted processes
2005-05-13 2:13 ` David Masover
@ 2005-05-13 4:05 ` Valdis.Kletnieks
0 siblings, 0 replies; 3+ messages in thread
From: Valdis.Kletnieks @ 2005-05-13 4:05 UTC (permalink / raw)
To: David Masover; +Cc: Bedros Hanounik, reiserfs-list
[-- Attachment #1.1: Type: text/plain, Size: 1569 bytes --]
On Thu, 12 May 2005 21:13:46 CDT, David Masover said:
> I bet this is what Hans was thinking of with "views". But views are
> much more global than "trusted processes". Specifically, views allow
> different degrees of "normal" processes.
>
> Other than that, I don't see how this is particularly helpful compared
> to UNIX security -- root is trusted, others aren't trusted, use ACLs if
> you need something complex.
That's good if you're working with discretionary access control (DAC) - both
ACLs and the rwx bits are examples of that.
If you're trying to implement mandatory access control (MAC), you need to take
a totally opposite approach - you need to design it such that even the file
*owner* is *not* able to grant access even if they want to - they can do 'chmod
777' and 'chacl -B' all they want, others can't get access if the site policy
doesn't permit it. (Dealing with all the odd corner cases is why things like
SELinux end up being complicated).
Those of you who are looking at "views" should probably take note of the
"Polyinstantation" thread on the 'Selinux@tycho.nsa.gov' list. I've attached
the overview of the patchkit - the other 5 parts of the patch kit really aren't
much use unless you have a crash&burn SELinux testbed handy. There's also some
implicit assumptions about having an MLS compartmentalized policy in place.
Unfortunately, I didn't keep all the postings on the thread.
The SELinux list is archived at http://www.nsa.gov/selinux/list-archive/ but
unfortunately only refreshed at irregular intervals (last was March 9).
[-- Attachment #1.2: forwarded message --]
[-- Type: message/rfc822, Size: 8325 bytes --]
From: Chad Sellers <cdselle@tycho.nsa.gov>
To: selinux@tycho.nsa.gov
Subject: [RFC]{Patch 0/5] Polyinstantation
Date: Wed, 11 May 2005 11:28:55 -0400
Message-ID: <1115825335.28084.27.camel@moss-huskies.epoch.ncsc.mil>
This patch us a userspace patch to provide polyinstantiation support in
SELinux. I am including a patch to libselinux to provide this, as well
as patches to login, su, gdm, and policy to make this work. These
patches will follow in separate emails. Comments are appreciated
(usually, at least).
OVERVIEW
This code provides polyinstantiation support for directories in SELinux
systems. It creates multiple instances of a directory as dictated by
policy. These instances are actually subdirectories, named using a MD5
hash of the context of the member directory, that are used in place of
the parent directory. To interface with policy, the code utilizes
the /selinux/member interface to read how directories should be
polyinstantiated according to policy.
In order to specify how directories should be instantiated in type
enforcement policy, a type_member rule is used. MLS polyinstantiation
policy is implicit (i.e. the directory should be polyinstantiated to the
level of the user). This code queries the /selinux/member interface to
see what member of a polyinstantiated directory should be used for a
given subject context.
To replace the original directory with the appropriate member directory,
per-process namespaces and bind mounts are used. More specifically, an
entrypoint program (say login) calls this library to see if any
polyinstantiation is necessary. If so, it calls clone() instead of fork
with the CLONE_NEWNS flag to get a new namespace. Then, the library can
bind mount member directories over the originals. Additionally, the
library remounts the original directory elsewhere (e.g. /tmp is
remounted to /.tmp-poly-orig) for security-aware (and allowed) programs
to utilize it.
USING THE LIBRARY
The library exports 2 functions, security_setupns(), the main function,
and security_set_setupns_printf(), a support function to change where
printf's go. security_setupns() sets up a namespace for the user being
processed. It takes one argument - commit, which is an integer that can
be 0 or 1. If commit=0, the function does not actually set up the
namespace, but just checks to see if any modifications to the namespace
are necessary. If commit=1, those modifications are actually made. The
function returns the number of changes (i.e. directories needing
polyinstantiation). security_set_setupns_printf is used to replace the
printf function (which defaults to logging to stderr) the same way that
set_matchpathcon_printf() does.
CONFIG FILE
There is one config file, which is stored in /etc/selinux/polydirs. The
first line contains the default context to use for directories that
originals are remounted to (e.g. /.tmp-poly-orig), which only matters
before the bind mount happens. The rest of the file is a newline-
delimited list of candidate directories to be polyinstantiated. Each of
these directories will be checked to see if polyinstantiation is
necessary according to the policy. Additionally, the library supports
the special directory $HOME to indicate the home directory of the user
who's environment we're setting up.
POLICY
Policy is fairly straightforward. Just write a type_member rule. The
syntax is:
type_member <source type> <target type>:<target class> <member type>
<source type> is the type of the user logging in, <target type> is the
type of the directory being polyinstantiated, <target class> is dir
(since this patch only works for directories), and <member type> is what
you want the member directory context to be. So, the rule
type_member user_t tmp_t:dir user_tmp_t
says use member directory user_tmp_t for a directory labeled tmp_t for
user_t. Of course, for this query to take place at all, you have to
have a directory in the config file that is labeled tmp_t.
Note that you also need appropriate policy (TE allow rules and mls
priveleges) to allow programs such as login, su, and gdm to perform the
appropriate functions. I've included a patch to policy to provide this.
BUILDING AND INSTALLING
The code is in the form of patches to the current cvs libselinux
(1.23.10-1), and the current rpms found in rawhide. I've enclosed both
patches to source and patches to the spec files. So, the easiest way to
install them, is to
1) Patch and rebuild your libselinux.
Build and install the SRPM -or-
tar xzf libselinux-x.y.z.tgz
cd libselinux-x.y.z
patch -p1 < libselinux-x.y.z-poly.patch
make install relabel
2) Apply the provided patch to your policy, build, and load it.
cd /etc/selinux/(strict|targeted|mls)/src/policy
patch -p1 < policy.diff
make load
Note: This includes domains/misc/test.te, which has example type member
rules. You may want to customize these to rules appropriate to your
install.
3) Install polydirs configuration file and edit for desired
configuration (which should match up with the type member rules above).
cp polydirs /etc/selinux/polydirs
4) Verify basic operation via setupns test utility (part of libselinux
patch).
su -
ls -al /tmp /home/<username>
setupns <username> <usercontext>
e.g. setupns jdoe user_u:user_r:user_t
ls -al /tmp /home/<username>
cat /proc/mounts
exit
setupns -X <username> <usercontext>
ls -al /tmp /home/<username>
5) Build and install the modified util-linux, coreutils, and gdm
Build and install the SRPMs -or-
Try applying patches to source from somewhere else. I have only tested
these patches with rawhide srpms, but they should be fairly easy to
apply to other source assuming that source already has the appropriate
SELinux patches.
6) Try logging into different roles at the console, via gdm, and using
su to switch between different users/roles, looking at your /tmp and
$HOME before and after, as well as /proc/mounts.
--
Chad Sellers
cdselle@tycho.nsa.gov
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread