[PATCH][RFC] Allow administrator control over per-user default_contexts

[PATCH][RFC] Allow administrator control over per-user default_contexts

[Stephen Smalley]

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

Hi,

A Fedora user expressed a desire to be able to have the administrator
control the per-user default_contexts configuration rather than allowing
users to specify their own prioritization via $HOME/.default_contexts.
This patch implements such support by changing libselinux to check for
the existence of an /etc/security/default_contexts.user directory.  If
the directory is present, then libselinux will check for a file named by
the username in that directory and use that file if it exists for any
per-user default_contexts ordering.  Only if the directory is not
present will libselinux check for $HOME/.default_contexts and use it. 
Thus, an administrator can simply create the directory to prohibit any
use of $HOME/.default_contexts and can then optionally chose to create
per-user configurations under it if desired.

Note that the use of $HOME/.default_contexts has never been well
supported by policy, as login/sshd typically lack permission to read
user home directory files and a separate type was never introduced for
per-user default_contexts.  While Fedora Core 2 is using a
/root/.default_contexts file, that is naturally administratively
controlled and labeled with default_context_t so that it can be accessed
by login/sshd.  But if we truly wanted to allow ordinary users to create
their own $HOME/.default_contexts files, we would need a separate type
for this purpose, e.g. $1_default_context_t for each user domain, allow
the user domains to create/relabel such files, and allow login/sshd to
read such files.

Questions:

- Does this change seem reasonable?

- Should the policy include support for the $HOME/.default_contexts
files for ordinary users?

- Should Fedora transition to using
/etc/security/default_contexts.user/root instead of
/root/.default_contexts, thus prohibiting use of $HOME/.default_contexts
by default?  Administrators who want to allow $HOME/.default_contexts
would then need to copy the root entry to /root/.default_contexts and
remove the directory to enable such support.

- Should the support for $HOME/.default_contexts be retained at all?

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

[-- Attachment #2: libselinux-usercon.patch --]
[-- Type: text/x-patch, Size: 1803 bytes --]

Index: libselinux/include/selinux/get_context_list.h
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/libselinux/include/selinux/get_context_list.h,v
retrieving revision 1.3
diff -u -r1.3 get_context_list.h
--- libselinux/include/selinux/get_context_list.h	6 Oct 2003 19:55:18 -0000	1.3
+++ libselinux/include/selinux/get_context_list.h	21 May 2004 14:53:02 -0000
@@ -4,6 +4,7 @@
 #include <selinux/selinux.h>
 
 #define _DEFCONTEXT_PATH "/etc/security/default_contexts"
+#define _DEFCONTEXT_USER_PATH "/etc/security/default_contexts.user"
 #define _FAILSAFECONTEXT_PATH "/etc/security/failsafe_context"
 #define SELINUX_DEFAULTUSER "user_u"
 
Index: libselinux/src/get_context_list.c
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/libselinux/src/get_context_list.c,v
retrieving revision 1.15
diff -u -r1.15 get_context_list.c
--- libselinux/src/get_context_list.c	16 Apr 2004 19:22:24 -0000	1.15
+++ libselinux/src/get_context_list.c	21 May 2004 14:59:45 -0000
@@ -213,8 +213,15 @@
     int retval;           /* The return value                          */
     long buflen;
 
-    if (which == USERPRIORITY)
-    {
+    if (which == USERPRIORITY && access(_DEFCONTEXT_USER_PATH, F_OK) == 0) {
+        fname_len = sizeof(_DEFCONTEXT_USER_PATH) + strlen(user) + 1;
+        fname = malloc (fname_len);
+        if (!fname) 
+            return -1;
+        sprintf (fname, "%s/%s", _DEFCONTEXT_USER_PATH, user);
+        config_file = fopen (fname, "r");
+	free (fname);
+    } else if (which == USERPRIORITY) {
         /* Get the password structure in order to find the home directory.
 	   Use getpwnam_r to avoid clobbering any existing pwd struct obtained
 	   by the caller. */

Re: [PATCH][RFC] Allow administrator control over per-user default_contexts

[Valdis.Kletnieks]

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

On Fri, 21 May 2004 12:02:55 EDT, Stephen Smalley said:

> - Does this change seem reasonable?

Yes.

It's quite reasonable to establish a site policy (as in "the way we do things"
not an selinux policy) that makes it as difficult as possible for users to
shortcut themselves into a more dangerous role setting ("Thou shalt login as a
mortal, and thou shalt have to explicitly request non-mortal status each time
you use it") - that's just good sysadmin practice and an extension of "dont run
as root".

And if a user has access to several roles, they should by default be placed in
the "least dangerous" role by default.   And if a site is letting the user
decide which one is "least dangerous", there's possibly something wrong
with the site's security stance.

Yes, I recognize that there are exceptions.  A user may have a 'user_r' role
that they're only in for a small part of a day, and also have a cobol_team_r
role that they're in on rare occasions, and a web_design_team_r role they spend
most of their time in, so the latter makes sense from a user effort standpoint
- but the site security officer should be acting as a check-n-balance on such a
change (if only to deliver a lecture on the importance of being careful while
in that role).

Of course, this depends a lot on the site's overall security stance - if the
site has a good security awareness program in place, or if the user is being
given several roles that are "close enough" in risk that it's difficult to
place a strict ordering on their dominance, the site may well have no problems
with letting users choose...

And I have to admit that although I agree with the request and the patch,
there's a a good number of systems in my own machine room where I'd be
hard pressed to argue in support of the change. ;)

Fortunately for all of us, the patch allows easy enough selection of the two
behaviors.. :)

> - Should the policy include support for the $HOME/.default_contexts
> files for ordinary users?

I'm ambivalent on this one.  I *will* firmly commit to the idea that *if* we
have a $HOME/.default_contexts file at all, that we need $1_default_context_t
and all the other policy rules/domains to do it *right*.

A related question - has anybody done scaling tests for this sort of thing for
large numbers of different values of $1?  I'm thinking about situations like
webhosting, where dozens/hundreds of logins might need this - it's unclear (at
least to me) at what point it becomes a Bad Idea to create per-user policies
and just dump all of them in "customer_t".

> - Should Fedora transition to using
> /etc/security/default_contexts.user/root instead of
> /root/.default_contexts, thus prohibiting use of $HOME/.default_contexts
> by default?  Administrators who want to allow $HOME/.default_contexts
> would then need to copy the root entry to /root/.default_contexts and
> remove the directory to enable such support.

That seems eminently sane as far as changing the default on new
installs.

It would be easy enough to add an RPM 'postinstall' scriptlet to auto-populate
/etc/security/default_contexts.user based on all $HOME values:

for i in `cut -f6 -d: /etc/passwd | sort -u`;
	if [ -f ${i}/.default_contexts && ! -f /etc/security/default_contexts.user/${i} ]; then
		cp ${i}/.default_contexts /etc/security/default_contexts.user/${i}
		# chown/chmod as needed here
	fi
done

but somehow that seems to violate the Principle of Least Surprise - it's the
sort of thing like 'pwconv' was - a good thing for the sysadmin to do, but the
sort of thing that I'd hate done to my system just because I ran an 'rpm
-Fvh'.. 

What do others think?

> - Should the support for $HOME/.default_contexts be retained at all?

Only if we fix the selinux policy issues.  If we can't, it should be lopped
out, but wanting to have things work that way is reasonable enough that
providing the choice of behaviors is a reasonable thing to do...


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH][RFC] Allow administrator control over per-user default_contexts

[Russell Coker]

On Sat, 22 May 2004 08:13, Valdis.Kletnieks@vt.edu wrote:
> On Fri, 21 May 2004 12:02:55 EDT, Stephen Smalley said:
> > - Does this change seem reasonable?
>
> Yes.

I agree.

However I am not certain that the existence of the directory should preclude 
any use of ~/.default_contexts.  Maybe only the existence of 
a /etc/security/selinux/default_contexts.user/username should be used to 
indicate that ~/.default_contexts should be ignored.

> > - Should the policy include support for the $HOME/.default_contexts
> > files for ordinary users?
>
> I'm ambivalent on this one.  I *will* firmly commit to the idea that *if*
> we have a $HOME/.default_contexts file at all, that we need
> $1_default_context_t and all the other policy rules/domains to do it
> *right*.

I agree.  Also we would have to write a utility to generate/modify the 
~/.default_contexts file.  Having users correctly label files under their 
home directory is painful.  It would be easy to write a script to make the 
current context the default and then set the type of the file correctly.

> A related question - has anybody done scaling tests for this sort of thing
> for large numbers of different values of $1?  I'm thinking about situations
> like webhosting, where dozens/hundreds of logins might need this - it's
> unclear (at least to me) at what point it becomes a Bad Idea to create
> per-user policies and just dump all of them in "customer_t".

The most I've used is ~36 user roles.  That didn't cause a problem so dozens 
seems OK to me.

> > - Should Fedora transition to using
> > /etc/security/default_contexts.user/root instead of
> > /root/.default_contexts, thus prohibiting use of $HOME/.default_contexts
> > by default?  Administrators who want to allow $HOME/.default_contexts
> > would then need to copy the root entry to /root/.default_contexts and
> > remove the directory to enable such support.
>
> That seems eminently sane as far as changing the default on new
> installs.

Makes sense to me.

> It would be easy enough to add an RPM 'postinstall' scriptlet to
> auto-populate /etc/security/default_contexts.user based on all $HOME
> values:

[...]

> but somehow that seems to violate the Principle of Least Surprise - it's
> the sort of thing like 'pwconv' was - a good thing for the sysadmin to do,
> but the sort of thing that I'd hate done to my system just because I ran an
> 'rpm -Fvh'..

I agree.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page

--
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.

Re: [PATCH][RFC] Allow administrator control over per-user default_contexts

[Stephen Smalley]

On Sun, 2004-05-23 at 16:12, Russell Coker wrote:
> However I am not certain that the existence of the directory should preclude 
> any use of ~/.default_contexts.  Maybe only the existence of 
> a /etc/security/selinux/default_contexts.user/username should be used to 
> indicate that ~/.default_contexts should be ignored.

Possibly, but then we need another method to allow an admin to
absolutely prohibit any use of $HOME/.default_contexts.  Requiring the
admin to create a stub entry under /etc/security/default_contexts.user
for every user just to prevent use of $HOME/.default_contexts is
unreasonable.  We could use the existence of another file, e.g.
/etc/security/default_contexts.user/ONLY, to indicate to libselinux that
it should only pull from that subdirectory and not from
$HOME/.default_contexts.

> I agree.  Also we would have to write a utility to generate/modify the 
> ~/.default_contexts file.  Having users correctly label files under their 
> home directory is painful.  It would be easy to write a script to make the 
> current context the default and then set the type of the file correctly.

True, or teach users to use restorecon on it after creation.

> > A related question - has anybody done scaling tests for this sort of thing
> > for large numbers of different values of $1?  I'm thinking about situations
> > like webhosting, where dozens/hundreds of logins might need this - it's
> > unclear (at least to me) at what point it becomes a Bad Idea to create
> > per-user policies and just dump all of them in "customer_t".

Sounds like Valdis may have misunderstood - the $1 corresponds to the
user role/domain, not the user identity.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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.

Re: [PATCH][RFC] Allow administrator control over per-user default_contexts

[Timothy]

On Monday 24 May 2004 08:43, Stephen Smalley wrote:
> On Sun, 2004-05-23 at 16:12, Russell Coker wrote:
> > However I am not certain that the existence of the directory should
> > preclude any use of ~/.default_contexts.  Maybe only the existence of
> > a /etc/security/selinux/default_contexts.user/username should be used to
> > indicate that ~/.default_contexts should be ignored.
>
> Possibly, but then we need another method to allow an admin to
> absolutely prohibit any use of $HOME/.default_contexts.  Requiring the
> admin to create a stub entry under /etc/security/default_contexts.user
> for every user just to prevent use of $HOME/.default_contexts is
> unreasonable.  We could use the existence of another file, e.g.
> /etc/security/default_contexts.user/ONLY, to indicate to libselinux that
> it should only pull from that subdirectory and not from
> $HOME/.default_contexts.

How about check for /etc/security/default_contexts.user/username and if it 
exists, ignore $HOME/.default_contexts.  Next 
check /etc/security/default_contexts.user/username for a valid context that 
is allowed by policy and if it does exist, then use that.  Otherwise use the 
system default. Then if an administrator wants to disable user set contexts 
an not set a specific one he can just create an empty file for that username 
in the /etc/security/default_contexts.user directory and no extra file would 
be needed.

>
> > I agree.  Also we would have to write a utility to generate/modify the
> > ~/.default_contexts file.  Having users correctly label files under their
> > home directory is painful.  It would be easy to write a script to make
> > the current context the default and then set the type of the file
> > correctly.
>
> True, or teach users to use restorecon on it after creation.
>
> > > A related question - has anybody done scaling tests for this sort of
> > > thing for large numbers of different values of $1?  I'm thinking about
> > > situations like webhosting, where dozens/hundreds of logins might need
> > > this - it's unclear (at least to me) at what point it becomes a Bad
> > > Idea to create per-user policies and just dump all of them in
> > > "customer_t".
>
> Sounds like Valdis may have misunderstood - the $1 corresponds to the
> user role/domain, not the user identity.

--
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.

Re: [PATCH][RFC] Allow administrator control over per-user default_contexts

[Stephen Smalley]

On Mon, 2004-05-24 at 10:04, Timothy wrote:
> How about check for /etc/security/default_contexts.user/username and if it 
> exists, ignore $HOME/.default_contexts.  Next 
> check /etc/security/default_contexts.user/username for a valid context that 
> is allowed by policy and if it does exist, then use that.  Otherwise use the 
> system default. Then if an administrator wants to disable user set contexts 
> an not set a specific one he can just create an empty file for that username 
> in the /etc/security/default_contexts.user directory and no extra file would 
> be needed.

The logic already allows for leaving the per-user default_contexts file
empty or incomplete; it always pulls the context lists from both the
per-user default_contexts file and the system default_contets file (with
the latter given lower precedence) and omits any contexts that would be
invalid for the user or unreachable from the calling context.  But the
approach you suggest still requires the admin to at least create an
empty file for every user account simply to disable use of
$HOME/.default_contexts, which is burdensome and error-prone if the
admin simply wants to disallow all use of $HOME/.default_contexts.  I
think we want a simple mechanism for the admin to express that goal
without needing to maintain per-user files at all, even empty ones.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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.

Re: [PATCH][RFC] Allow administrator control over per-user default_contexts

[Luke Kenneth Casson Leighton]

hi,

uhm, not being funny or anything but is there a simpler approach
to all this?

might i make a suggestion based on what i know of NT security
descriptors (formerly known as VAX/VMS security before dave cutler
went to work for microsoft it's a long story :)

NT security descriptors are not 32-bits but can vary between
about 5 bytes and approx 16.  they consist of a prefix which
is the domain and the very last word (suffix) represents a
user or a group.  btw i am very surprised that the opportunity
to extend the size of security descriptors to a world-size
view (i.e. outside of a single machine) i.e. beyond 32-bit
and to 128-bit or more.  but i digress.

in NT 4.0 SD model, the concept of "local groups" was introduced
but for NT 5.0 (aka 2000) the distinction was removed at the
risk of also introducing circular group membership dependencies.

the important bit that i wanted to mention to you is that in
the NT security model GROUPS can own objects (files, processes
etc).

this is distinctly different from unix, whereby only users can
own files (and it causes a lot of problems for anyone implementing
an SMB server if they choose to map direct to any kind of
unix file system rather than provide their own)
 

groups being able to own objects means greatly simplified management.

so, what i was wondering: is there a similar such concept in
SE/Linux, with domains?


On Mon, May 24, 2004 at 10:27:29AM -0400, Stephen Smalley wrote:
> On Mon, 2004-05-24 at 10:04, Timothy wrote:
> > How about check for /etc/security/default_contexts.user/username and if it 
> > exists, ignore $HOME/.default_contexts.  Next 
> > check /etc/security/default_contexts.user/username for a valid context that 
> > is allowed by policy and if it does exist, then use that.  Otherwise use the 
> > system default. Then if an administrator wants to disable user set contexts 
> > an not set a specific one he can just create an empty file for that username 
> > in the /etc/security/default_contexts.user directory and no extra file would 
> > be needed.
> 
> The logic already allows for leaving the per-user default_contexts file
> empty or incomplete; it always pulls the context lists from both the
> per-user default_contexts file and the system default_contets file (with
> the latter given lower precedence) and omits any contexts that would be
> invalid for the user or unreachable from the calling context.  But the
> approach you suggest still requires the admin to at least create an
> empty file for every user account simply to disable use of
> $HOME/.default_contexts, which is burdensome and error-prone if the
> admin simply wants to disallow all use of $HOME/.default_contexts.  I
> think we want a simple mechanism for the admin to express that goal
> without needing to maintain per-user files at all, even empty ones.
> 
> -- 
> Stephen Smalley <sds@epoch.ncsc.mil>
> National Security Agency
> 
> 
> --
> 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.

-- 
-- 
expecting email to be received and understood is a bit like
picking up the telephone and immediately dialing without
checking for a dial-tone; speaking immediately without listening
for either an answer or ring-tone; hanging up immediately and
believing that you have actually started a conversation.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
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.

Re: [PATCH][RFC] Allow administrator control over per-user default_contexts

[Stephen Smalley]

On Tue, 2004-05-25 at 04:37, Luke Kenneth Casson Leighton wrote:
> the important bit that i wanted to mention to you is that in
> the NT security model GROUPS can own objects (files, processes
> etc).
> 
> this is distinctly different from unix, whereby only users can
> own files (and it causes a lot of problems for anyone implementing
> an SMB server if they choose to map direct to any kind of
> unix file system rather than provide their own)
>  
> 
> groups being able to own objects means greatly simplified management.
> 
> so, what i was wondering: is there a similar such concept in
> SE/Linux, with domains?

Objects are labeled with security types, processes are labeled with
security domains, and an access matrix defines allowable interactions
among them.  We were talking about derived types, i.e. types that encode
information about both the creating domain and object type and preserve
separation among the domains, e.g. user_default_context_t for
$HOME/.default_contexts files created by user_r:user_t processes.  This
is commonly done via parameterized macros in the policy configuration.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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.

Re: [PATCH][RFC] Allow administrator control over per-user default_contexts

[Timothy]

On Monday 24 May 2004 08:43, Stephen Smalley wrote:
> Requiring the
> admin to create a stub entry under /etc/security/default_contexts.user
> for every user just to prevent use of $HOME/.default_contexts is
> unreasonable. 

Scratch what I said. I somehow misread that..

--
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.

Re: [PATCH][RFC] Allow administrator control over per-user default_contexts

[Valdis.Kletnieks]

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

On Mon, 24 May 2004 08:43:53 EDT, Stephen Smalley said:

> Sounds like Valdis may have misunderstood - the $1 corresponds to the
> user role/domain, not the user identity.

No, I was clear on that distinction (and was counting "domains" as being more
akin to group membership).  On the other hand, I've had the joy of running
larger systems back in the "old days" when NGROUPS_MAX was still 8 or 16 or
whatever it was for NFS back in SunOS 3.5/4.0 days, and I had literally a dozen
users pegged at the group limit (doesn't take long, when you have a 'cs_dept'
group, then a "these 3 CS profs and 1 EE prof", a "same EE prof and 2 guys from
Physics", and... you get the idea..).   One of our production machines (which
has end-user userids on it) currently has 314 users and 273 groups defined....

I've gotten burnt too many times when a user who's in multiple groups has
managed to screw things up with a 'chgrp' command (between the -R flag and file
globbing, chgrp and chmod are dangerous for users ;) - so there's a real
temptation to use roles to build a much higher wall between the contexts. And
using the one production machine as an example, it's not at all clear that
there is any really sensible halfway point between 300 people in 1 user_t
domain and 250 domains with single-digit numbers of users...


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: [PATCH][RFC] Allow administrator control over per-user default_contexts

[Stephen Smalley]

On Mon, 2004-05-24 at 13:25, Valdis.Kletnieks@vt.edu wrote:
> No, I was clear on that distinction (and was counting "domains" as being more
> akin to group membership).  On the other hand, I've had the joy of running
> larger systems back in the "old days" when NGROUPS_MAX was still 8 or 16 or
> whatever it was for NFS back in SunOS 3.5/4.0 days, and I had literally a dozen
> users pegged at the group limit (doesn't take long, when you have a 'cs_dept'
> group, then a "these 3 CS profs and 1 EE prof", a "same EE prof and 2 guys from
> Physics", and... you get the idea..).   One of our production machines (which
> has end-user userids on it) currently has 314 users and 273 groups defined....
> 
> I've gotten burnt too many times when a user who's in multiple groups has
> managed to screw things up with a 'chgrp' command (between the -R flag and file
> globbing, chgrp and chmod are dangerous for users ;) - so there's a real
> temptation to use roles to build a much higher wall between the contexts. And
> using the one production machine as an example, it's not at all clear that
> there is any really sensible halfway point between 300 people in 1 user_t
> domain and 250 domains with single-digit numbers of users...

Ok, but adding a $1_default_context_t type isn't going to make much of
an impact here, as there are already a number of $1_foo_t domains and
types derived from the base user domains.  Looks like we have around 25
domains and 44 file types defined for each of the user roles at present.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
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.

Re: [PATCH][RFC] Allow administrator control over per-user default_contexts

[Stephen Smalley]

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

On Mon, 2004-05-24 at 08:43, Stephen Smalley wrote:
> On Sun, 2004-05-23 at 16:12, Russell Coker wrote:
> > However I am not certain that the existence of the directory should preclude 
> > any use of ~/.default_contexts.  Maybe only the existence of 
> > a /etc/security/selinux/default_contexts.user/username should be used to 
> > indicate that ~/.default_contexts should be ignored.
> 
> Possibly, but then we need another method to allow an admin to
> absolutely prohibit any use of $HOME/.default_contexts.  Requiring the
> admin to create a stub entry under /etc/security/default_contexts.user
> for every user just to prevent use of $HOME/.default_contexts is
> unreasonable.  We could use the existence of another file, e.g.
> /etc/security/default_contexts.user/ONLY, to indicate to libselinux that
> it should only pull from that subdirectory and not from
> $HOME/.default_contexts.

Below is an updated patch that uses the existence of a separate
/etc/security/default_contexts.user/.force file as an indicator that the
administrator does not want to allow use of $HOME/.default_contexts at
all.  Hence, the new logic first checks for
/etc/security/default_contexts.user/$USER and uses that file if it
exists; otherwise, it checks for the .force file to determine whether or
not to check for $HOME/.default_contexts.  As before, the logic still
pulls in the system default_contexts entries afterwards, and omits any
invalid contexts for the user or unreachable contexts from the caller. 
If this looks ok, we'll make this change (although the final location of
the default_contexts.user directory may change due to some other
discussions about rearranging the SELinux config file layout and
supporting multiple policies).

 
-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

[-- Attachment #2: libselinux-usercon.patch2 --]
[-- Type: text/x-patch, Size: 2258 bytes --]

Index: libselinux/include/selinux/get_context_list.h
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/libselinux/include/selinux/get_context_list.h,v
retrieving revision 1.3
diff -u -r1.3 get_context_list.h
--- libselinux/include/selinux/get_context_list.h	6 Oct 2003 19:55:18 -0000	1.3
+++ libselinux/include/selinux/get_context_list.h	25 May 2004 14:21:31 -0000
@@ -4,6 +4,8 @@
 #include <selinux/selinux.h>
 
 #define _DEFCONTEXT_PATH "/etc/security/default_contexts"
+#define _DEFCONTEXT_USER_PATH "/etc/security/default_contexts.user"
+#define _DEFCONTEXT_USER_PATH_FORCE "/etc/security/default_contexts.user/.force"
 #define _FAILSAFECONTEXT_PATH "/etc/security/failsafe_context"
 #define SELINUX_DEFAULTUSER "user_u"
 
Index: libselinux/src/get_context_list.c
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/libselinux/src/get_context_list.c,v
retrieving revision 1.15
diff -u -r1.15 get_context_list.c
--- libselinux/src/get_context_list.c	16 Apr 2004 19:22:24 -0000	1.15
+++ libselinux/src/get_context_list.c	25 May 2004 14:26:48 -0000
@@ -213,8 +213,20 @@
     int retval;           /* The return value                          */
     long buflen;
 
-    if (which == USERPRIORITY)
-    {
+    if (which == USERPRIORITY) {
+        /* Check for an admin-defined per-user default_contexts file first. */
+        fname_len = sizeof(_DEFCONTEXT_USER_PATH) + strlen(user) + 1;
+        fname = malloc (fname_len);
+        if (!fname) 
+            return -1;
+        sprintf (fname, "%s/%s", _DEFCONTEXT_USER_PATH, user);
+        config_file = fopen (fname, "r");
+	free (fname);
+	/* If the admin has created a per-user default_contexts file or 
+	   the admin has created .force file, then do not attempt to 
+	   open a $HOME/.default_contexts file for the user. */
+	if (config_file || (access(_DEFCONTEXT_USER_PATH_FORCE, F_OK) == 0))
+		goto out;
         /* Get the password structure in order to find the home directory.
 	   Use getpwnam_r to avoid clobbering any existing pwd struct obtained
 	   by the caller. */
@@ -263,6 +275,7 @@
         return -1;
     }
 
+out:
     if (!config_file)
     {
         return -1;

Re: [PATCH][RFC] Allow administrator control over per-user default_contexts

[Daniel J Walsh]

Stephen Smalley wrote:

>On Mon, 2004-05-24 at 08:43, Stephen Smalley wrote:
>  
>
>>On Sun, 2004-05-23 at 16:12, Russell Coker wrote:
>>    
>>
>>>However I am not certain that the existence of the directory should preclude 
>>>any use of ~/.default_contexts.  Maybe only the existence of 
>>>a /etc/security/selinux/default_contexts.user/username should be used to 
>>>indicate that ~/.default_contexts should be ignored.
>>>      
>>>
>>Possibly, but then we need another method to allow an admin to
>>absolutely prohibit any use of $HOME/.default_contexts.  Requiring the
>>admin to create a stub entry under /etc/security/default_contexts.user
>>for every user just to prevent use of $HOME/.default_contexts is
>>unreasonable.  We could use the existence of another file, e.g.
>>/etc/security/default_contexts.user/ONLY, to indicate to libselinux that
>>it should only pull from that subdirectory and not from
>>$HOME/.default_contexts.
>>    
>>
>
>Below is an updated patch that uses the existence of a separate
>/etc/security/default_contexts.user/.force file as an indicator that the
>administrator does not want to allow use of $HOME/.default_contexts at
>all.  Hence, the new logic first checks for
>/etc/security/default_contexts.user/$USER and uses that file if it
>exists; otherwise, it checks for the .force file to determine whether or
>not to check for $HOME/.default_contexts.  As before, the logic still
>pulls in the system default_contexts entries afterwards, and omits any
>invalid contexts for the user or unreachable contexts from the caller. 
>If this looks ok, we'll make this change (although the final location of
>the default_contexts.user directory may change due to some other
>discussions about rearranging the SELinux config file layout and
>supporting multiple policies).
>
>  
>
I see very little reason to continue supporting ~/.default_contexts.  I 
think that the new design allows for specific users to have different 
context but that is controlled by the admin.  Users most likely will not 
understand the contents of the .default_contexts files and those that do 
can probably get an admin to change the system wide one.  The amount of 
headaches of maintaining .default_contexts under a correct security 
context and having the user screw up his file is great.  I vote to just 
get rid of it.

Dan

> 
>  
>
>------------------------------------------------------------------------
>
>Index: libselinux/include/selinux/get_context_list.h
>===================================================================
>RCS file: /nfshome/pal/CVS/selinux-usr/libselinux/include/selinux/get_context_list.h,v
>retrieving revision 1.3
>diff -u -r1.3 get_context_list.h
>--- libselinux/include/selinux/get_context_list.h	6 Oct 2003 19:55:18 -0000	1.3
>+++ libselinux/include/selinux/get_context_list.h	25 May 2004 14:21:31 -0000
>@@ -4,6 +4,8 @@
> #include <selinux/selinux.h>
> 
> #define _DEFCONTEXT_PATH "/etc/security/default_contexts"
>+#define _DEFCONTEXT_USER_PATH "/etc/security/default_contexts.user"
>+#define _DEFCONTEXT_USER_PATH_FORCE "/etc/security/default_contexts.user/.force"
> #define _FAILSAFECONTEXT_PATH "/etc/security/failsafe_context"
> #define SELINUX_DEFAULTUSER "user_u"
> 
>Index: libselinux/src/get_context_list.c
>===================================================================
>RCS file: /nfshome/pal/CVS/selinux-usr/libselinux/src/get_context_list.c,v
>retrieving revision 1.15
>diff -u -r1.15 get_context_list.c
>--- libselinux/src/get_context_list.c	16 Apr 2004 19:22:24 -0000	1.15
>+++ libselinux/src/get_context_list.c	25 May 2004 14:26:48 -0000
>@@ -213,8 +213,20 @@
>     int retval;           /* The return value                          */
>     long buflen;
> 
>-    if (which == USERPRIORITY)
>-    {
>+    if (which == USERPRIORITY) {
>+        /* Check for an admin-defined per-user default_contexts file first. */
>+        fname_len = sizeof(_DEFCONTEXT_USER_PATH) + strlen(user) + 1;
>+        fname = malloc (fname_len);
>+        if (!fname) 
>+            return -1;
>+        sprintf (fname, "%s/%s", _DEFCONTEXT_USER_PATH, user);
>+        config_file = fopen (fname, "r");
>+	free (fname);
>+	/* If the admin has created a per-user default_contexts file or 
>+	   the admin has created .force file, then do not attempt to 
>+	   open a $HOME/.default_contexts file for the user. */
>+	if (config_file || (access(_DEFCONTEXT_USER_PATH_FORCE, F_OK) == 0))
>+		goto out;
>         /* Get the password structure in order to find the home directory.
> 	   Use getpwnam_r to avoid clobbering any existing pwd struct obtained
> 	   by the caller. */
>@@ -263,6 +275,7 @@
>         return -1;
>     }
> 
>+out:
>     if (!config_file)
>     {
>         return -1;
>  
>


--
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.

Re: [PATCH][RFC] Allow administrator control over per-user default_contexts

[Stephen Smalley]

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

On Tue, 2004-05-25 at 14:15, Daniel J Walsh wrote:
> I see very little reason to continue supporting ~/.default_contexts.  I 
> think that the new design allows for specific users to have different 
> context but that is controlled by the admin.  Users most likely will not 
> understand the contents of the .default_contexts files and those that do 
> can probably get an admin to change the system wide one.  The amount of 
> headaches of maintaining .default_contexts under a correct security 
> context and having the user screw up his file is great.  I vote to just 
> get rid of it.

That would simplify matters.  Below is an updated patch that drops the
old ~/.default_contexts logic entirely, and only checks for
/etc/security/default_contexts.user/$USER for the per-user
default_contexts configuration.  As with the prior patch, the location
is likely to change due to the reorganization of the SELinux
configuration file layout proposed by Dan.  From Dan's posting, it looks
like it will become /etc/selinux/(strict|targeted)/contexts/users/$USER.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency

[-- Attachment #2: libselinux-usercon.patch3 --]
[-- Type: text/x-patch, Size: 2955 bytes --]

Index: libselinux/include/selinux/get_context_list.h
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/libselinux/include/selinux/get_context_list.h,v
retrieving revision 1.3
diff -u -r1.3 get_context_list.h
--- libselinux/include/selinux/get_context_list.h	6 Oct 2003 19:55:18 -0000	1.3
+++ libselinux/include/selinux/get_context_list.h	26 May 2004 11:43:47 -0000
@@ -4,6 +4,7 @@
 #include <selinux/selinux.h>
 
 #define _DEFCONTEXT_PATH "/etc/security/default_contexts"
+#define _DEFCONTEXT_USER_PATH "/etc/security/default_contexts.user"
 #define _FAILSAFECONTEXT_PATH "/etc/security/failsafe_context"
 #define SELINUX_DEFAULTUSER "user_u"
 
Index: libselinux/src/get_context_list.c
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/libselinux/src/get_context_list.c,v
retrieving revision 1.15
diff -u -r1.15 get_context_list.c
--- libselinux/src/get_context_list.c	16 Apr 2004 19:22:24 -0000	1.15
+++ libselinux/src/get_context_list.c	26 May 2004 11:49:52 -0000
@@ -208,50 +208,21 @@
     FILE *config_file;    /* The configuration file                    */
     char *fname = 0;      /* The name of the user's configuration file */
     size_t fname_len;     /* The length of fname                       */
-    struct passwd pwdbuf, *pwd = &pwdbuf;   
-    char *buf;
     int retval;           /* The return value                          */
-    long buflen;
 
     if (which == USERPRIORITY)
     {
-        /* Get the password structure in order to find the home directory.
-	   Use getpwnam_r to avoid clobbering any existing pwd struct obtained
-	   by the caller. */
-	buflen = sysconf(_SC_GETPW_R_SIZE_MAX);
-	if (buflen < 0)
-		return -1;
-	buf = malloc(buflen);
-	if (!buf)
-		return -1;
-	retval = getpwnam_r (user, pwd, buf, buflen, &pwd );
-	while (retval < 0 && errno == ERANGE) {
-		char *newbuf;
-		errno = 0;
-		buflen *= 2;
-		newbuf = realloc (buf, buflen);
-		if (!newbuf) {
-			free(buf);
-			return -1;
-		}
-		buf = newbuf;
-		retval = getpwnam_r (user, pwd, buf, buflen, &pwd );
-	}
-        if (retval < 0 || !pwd) {
-		free(buf);
-		return -1;
-        }
-        fname_len = strlen (pwd->pw_dir) + 20;
-        fname = malloc (fname_len);
-        if (!fname) 
-        {
-	    free(buf);
-            return -1;
-        }
-        sprintf (fname, "%s%s", pwd->pw_dir, "/.default_contexts");
-        config_file = fopen (fname, "r");
-	free (fname);
-        free(buf);
+	    fname_len = sizeof(_DEFCONTEXT_USER_PATH) + strlen(user) + 1;
+	    fname = malloc (fname_len);
+	    if (!fname) 
+		    return -1;
+	    retval = snprintf (fname, fname_len, "%s/%s", _DEFCONTEXT_USER_PATH, user);
+	    if (retval < 0 || (size_t)retval >= fname_len) {
+		    free(fname);
+		    return -1;
+	    }
+	    config_file = fopen (fname, "r");
+	    free (fname);
     }
     else if (which == SYSTEMPRIORITY)
     {