trusted processes

trusted processes

[Bedros Hanounik]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

last year, I asked a question on this list whether we could have file 
permissions for programs (or processes) in addition to users and groups. we 
need this feature to reject malicious code from accessing system files.

Microsoft has a tech paper about having what they call trusted processes. 
you can find it here 

http://msdn.microsoft.com/mobility/default.aspx?pull=/library/en-us/dnppcgen/html/wmsecurity.asp

I don't know for how long they've been working on this, but I bet I came up 
with this concept first.

what do you think guys of implementing such feature; should it be in the 
file system, kernel, or both. 

How hard is it to implement, besides the complexity of authentication 
management.

-B

[-- Attachment #2: Type: text/html, Size: 898 bytes --]

Re: trusted processes

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bedros Hanounik wrote:
> last year, I asked a question on this list whether we could have file
> permissions for programs (or processes) in addition to users and groups.
> we need this feature to reject malicious code from accessing system files.
> 
> Microsoft has a tech paper about having what they call trusted
> processes. you can find it here
> 
> http://msdn.microsoft.com/mobility/default.aspx?pull=/library/en-us/dnppcgen/html/wmsecurity.asp
> 
> I don't know for how long they've been working on this, but I bet I came
> up with this concept first.

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.

Until something comes along that's as simple as UNIX but does at least
as much as ACLs, I'm going to avoid talking about security on the level
of an assumed-compromised system.

> what do you think guys of implementing such feature; should it be in the
> file system, kernel, or both.

Kernel.  It should apply to more than just files.  Ideally, you want to
be able to have kernel APIs which only certain processes can call.  I
think this can be done without slowing down the unaffected APIs.

> How hard is it to implement, besides the complexity of authentication
> management.

Ask someone else.  Or better, look at archives on "views" from about a
month ago, or whenever it was that I was brainstorming with someone
about how the user would control / be controlled by views.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQoQNWngHNmZLgCUhAQKeUw//d7qJkKZKOUn9zjrIJTPqe73DjXLsYNeB
En3x5HRhfRduXg9OB6bnHByglR0IsXM+FegVNcknMHfLRANBCIDMNOIca34c/wVq
58f/18wSNiw4DJs9sqW+tEYIt9HnyG2mNa3hUOp3SXg/+VDzXPsbMbhEDhigcfsb
FXLuzWZoCHFhvziyWV++6FuOZmlHDmRBw8MY3FZtFjjxcIH8zhDt7UDM7m5kmklY
Ossi5nCK36C8Hi4vtL5gK2f5NoCY3A7a+hfBoTyXsYrwWR0635njN7vONdJMDPp9
cOmHr/iqttisdQT105ErjcnvofBG/LjvFKbPEQ/2S1h1rao8epIgd70t67Y8aG3G
VvNXQzSIsfF4rMEpHlY0GoLsesZgyXvIMYjtMA7jypPuw9Ra5/qz16LubzSNE3Xo
tmTFwS+iXOvfXBPWjd7GFJiS+8tCnZ95He3v0qvt1s6n4IEj7FRMNoQZYlNDmzj7
UhqqL6hbDONzpWJBHv2NoK2DYez5pZ0y+HmSSU36EwD3KIbhtuQSJaVG42zWBg3n
o5W6nPBHUPPbW2UuG4Ww0D2UsMWaUJMHhAa2wew8sBxBbohcn4w2yHnjcXHzxA2K
i7bcoAcPvIORBKgo/QsBw74t7gsugzNcKaJJQM+h1e1wOmDvwi4ZbnnlZqp5WI49
9C4ToF7DoXI=
=AUW0
-----END PGP SIGNATURE-----

Re: trusted processes

[Valdis.Kletnieks]

[-- 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 --]