Category Translation patch for MCS/MLS Policy

Category Translation patch for MCS/MLS Policy

[Daniel J Walsh]

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

I have written up a patch for libselinux to implement two functions, to 
translate the security level.

getselevelbyname
getselevelbysename
setransconlevel

These functions try to dlopen a libsetrans and call the equivalent 
functions in this library.
Currently the patch only changes the *getfilecon function calls use 
these translations.
I have also attached a libsetrans-0.1.0-src.rpm  which would be the 
translation library for MCS.

I am not sure if a similar library was proposed by TCS or not,  I can 
not find it.  This is a lot simpler than
what Ivan proposed last week. 

Manipulation of securitylevel is to be done by the provider of the 
translation library (setrans).  So that a MLS environment
can use the Mitre library to translate, while MCS can use much simpler 
algorithms.

My demo libsetrans does the following

* If Security level is S0, remove security level all together.  I don't 
want users seeing this, since it is pretty useless information.
It would be nice to get rid of "object_r" also since it takes up 
terminal space and supplies Zero information.

* If a file has a security context other than S0, strip SO: off of it 
and pass it to the translation function calls. 
    Currently these calls only take a single category.
* If there is no translation it returns the category.

The categories in MCS are currently just loaded from a flat file 
/etc/selinux/category.conf. 
c1=Medical Records
c2=Top Secret
c3=Company Confidential
Eventually this will be configurable so this data could come from an 
ldap server, maybe it could be rolled into nsswitch.


Example output  (libselinux has sensivity level s0,  install.log.syslog 
has s0:c2)

ls -lZ /root
-rw-------  root     root     root:object_r:user_home_t:Top Secret 
anaconda-ks.cfg
-rw-r--r--  root     root     root:object_r:tmp_t:Medical Records dan
-rw-r--r--  root     root     root:object_r:user_home_t:Top Secret 
install.log
-rw-r--r--  root     root     root:object_r:user_home_t:c4 
install.log.syslog
-rw-r--r--  root     root     root:object_r:user_home_t        
libselinux-1.24.2-2.src.rpm


Comments?
Did I reimplement something that others already implemented?  Is this 
what people expect?

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

diff --exclude-from=exclude -N -u -r nsalibselinux/include/selinux/setrans.h libselinux-1.24.2/include/selinux/setrans.h
--- nsalibselinux/include/selinux/setrans.h	1969-12-31 19:00:00.000000000 -0500
+++ libselinux-1.24.2/include/selinux/setrans.h	2005-08-05 09:56:54.000000000 -0400
@@ -0,0 +1,27 @@
+#ifndef _SETRANS_H_
+#define _SETRANS_H_
+
+#include <selinux/selinux.h>
+
+/* Define data structures */
+typedef struct selevel {
+	char* name;
+	char* sename;
+} selevel_t;
+
+/* Category data structure */
+/* Data returned from the getselevel functions must be freed using freelevel */
+
+/* Get Security Level translation struct via internal Name */
+extern struct selevel *getselevelbyname(const char *name);
+
+/* Get Security Level translation struct via external Name */
+extern struct selevel *getselevelbysename( const char* sename);
+
+/* Function used to free data returned via getselevel functions */
+extern void freeselevel( selevel_t *level);
+
+/* Translate security context, into exernal representation */
+extern char *setransconlevel(const security_context_t con);
+
+#endif
diff --exclude-from=exclude -N -u -r nsalibselinux/man/man8/selinuxenabled.8 libselinux-1.24.2/man/man8/selinuxenabled.8
--- nsalibselinux/man/man8/selinuxenabled.8	2004-11-02 14:26:19.000000000 -0500
+++ libselinux-1.24.2/man/man8/selinuxenabled.8	2005-08-05 09:47:55.000000000 -0400
@@ -7,7 +7,7 @@
 .SH "DESCRIPTION"
 .B selinuxenabled
 Indicates whether SELinux is enabled or disabled. It exits with status 0 
-if SELinux is enabled and -256 if it is not enabled.
+if SELinux is enabled and 1 if it is not enabled.
 
 .SH AUTHOR	
 Dan Walsh, <dwalsh@redhat.com>
diff --exclude-from=exclude -N -u -r nsalibselinux/src/context.c libselinux-1.24.2/src/context.c
--- nsalibselinux/src/context.c	2005-01-28 12:15:29.000000000 -0500
+++ libselinux-1.24.2/src/context.c	2005-08-05 09:47:55.000000000 -0400
@@ -134,20 +134,27 @@
 
 static int set_comp(context_private_t* n,int index, const char *str)
 {
-        char *t = (char*) malloc(strlen(str)+1);
-        const char *p;
-        if ( !t ) { return 1; }
-        for ( p = str; *p; p++ ) {
-                if ( *p == '\t' || *p == ' ' || *p == '\n' || *p == '\r' ||
-                     (*p == ':' && index != COMP_RANGE) ) {
-                        free(t);
-                        return 1;
-                }
-        }
-        conditional_free(&n->component[index]);
-        n->component[index] = t;
-        strcpy(t,str);
-        return 0;
+	char *t;
+	
+	if (str) {
+		t = (char*) malloc(strlen(str)+1);
+		const char *p;
+		if ( !t ) { return 1; }
+		for ( p = str; *p; p++ ) {
+			if ( *p == '\t' || *p == '\n' || *p == '\r' ||
+			     (*p == ':' && index != COMP_RANGE) ) {
+				free(t);
+				return 1;
+			}
+		}
+		conditional_free(&n->component[index]);
+		n->component[index] = t;
+		strcpy(t,str);
+	} else {
+		conditional_free(&n->component[index]);
+		n->component[index] = NULL;
+	}
+	return 0;
 }
 
 #define def_get(name,tag) \
diff --exclude-from=exclude -N -u -r nsalibselinux/src/fgetfilecon.c libselinux-1.24.2/src/fgetfilecon.c
--- nsalibselinux/src/fgetfilecon.c	2004-10-20 16:31:36.000000000 -0400
+++ libselinux-1.24.2/src/fgetfilecon.c	2005-08-05 09:47:55.000000000 -0400
@@ -6,6 +6,7 @@
 #include <errno.h>
 #include <sys/xattr.h>
 #include "policy.h"
+#include <selinux/setrans.h>
 
 int fgetfilecon(int fd, security_context_t *context)
 {
@@ -37,9 +38,8 @@
 		ret = fgetxattr(fd, XATTR_NAME_SELINUX, buf, size-1); 
 	}
 out:			
-	if (ret < 0)
-		free(buf);
-	else
-		*context = buf;
+	if (ret >= 0)
+		*context = setransconlevel(buf);
+       free(buf);
 	return ret;
 }
diff --exclude-from=exclude -N -u -r nsalibselinux/src/getcon.c libselinux-1.24.2/src/getcon.c
--- nsalibselinux/src/getcon.c	2004-10-20 16:31:36.000000000 -0400
+++ libselinux-1.24.2/src/getcon.c	2005-08-05 09:47:55.000000000 -0400
@@ -30,7 +30,7 @@
 	if (ret < 0)
 		goto out2;
 
-	*context = strdup(buf);
+	*context = setransconlevel(buf);
 	if (!(*context)) {
 		ret = -1;
 		goto out2;
diff --exclude-from=exclude -N -u -r nsalibselinux/src/getfilecon.c libselinux-1.24.2/src/getfilecon.c
--- nsalibselinux/src/getfilecon.c	2005-01-28 12:15:29.000000000 -0500
+++ libselinux-1.24.2/src/getfilecon.c	2005-08-05 09:47:55.000000000 -0400
@@ -6,6 +6,7 @@
 #include <errno.h>
 #include <sys/xattr.h>
 #include "policy.h"
+#include <selinux/setrans.h>
 
 int getfilecon(const char *path, security_context_t *context)
 {
@@ -37,10 +38,9 @@
 		ret = getxattr(path, XATTR_NAME_SELINUX, buf, size-1); 
 	}
 out:			
-	if (ret < 0)
-		free(buf);
-	else
-		*context = buf;
+	if (ret >= 0)
+		*context = setransconlevel(buf);
+	free(buf);
 	return ret;
 }
 hidden_def(getfilecon)
diff --exclude-from=exclude -N -u -r nsalibselinux/src/getpidcon.c libselinux-1.24.2/src/getpidcon.c
--- nsalibselinux/src/getpidcon.c	2004-10-20 16:31:36.000000000 -0400
+++ libselinux-1.24.2/src/getpidcon.c	2005-08-05 09:47:55.000000000 -0400
@@ -34,7 +34,7 @@
 	if (ret < 0)
 		goto out2;
 
-	*context = strdup(buf);
+	*context = setransconlevel(buf);
 	if (!(*context)) {
 		ret = -1;
 		goto out2;
diff --exclude-from=exclude -N -u -r nsalibselinux/src/lgetfilecon.c libselinux-1.24.2/src/lgetfilecon.c
--- nsalibselinux/src/lgetfilecon.c	2004-10-20 16:31:36.000000000 -0400
+++ libselinux-1.24.2/src/lgetfilecon.c	2005-08-05 09:47:55.000000000 -0400
@@ -37,9 +37,8 @@
 		ret = lgetxattr(path, XATTR_NAME_SELINUX, buf, size-1); 
 	}
 out:			
-	if (ret < 0)
-		free(buf);
-	else
-		*context = buf;
+	if (ret >= 0)
+		*context = setransconlevel(buf);
+	free(buf);
 	return ret;
 }
diff --exclude-from=exclude -N -u -r nsalibselinux/src/setrans.c libselinux-1.24.2/src/setrans.c
--- nsalibselinux/src/setrans.c	1969-12-31 19:00:00.000000000 -0500
+++ libselinux-1.24.2/src/setrans.c	2005-08-05 09:51:03.000000000 -0400
@@ -0,0 +1,71 @@
+#include <unistd.h>
+#include <fcntl.h>
+#include <stdlib.h>
+#include <string.h>
+#include <selinux/setrans.h>
+#include <selinux/context.h>
+#include <dlfcn.h>
+
+static selevel_t *(*setrans_selevelbyname)( const char* name);
+static selevel_t *(*setrans_selevelbysename)( const char* sename);
+
+void freeselevel( selevel_t *level) {
+	if (level->name) 
+		free(level->name);
+	if (level->sename) 
+		free(level->sename);
+	free(level);
+}
+
+/* Find and load the Security Level translation library */
+static int getlibsetrans(void) {
+	static void *handle = NULL;
+	char *error;
+	if (handle) {
+		return 0;
+	}
+	handle = dlopen ("libsetrans.so", RTLD_LAZY);
+	if (!handle)
+		return 1;
+	dlerror();
+	*(selevel_t **) (&setrans_selevelbyname) = dlsym(handle, "setrans_getselevelbyname");
+	if ((error = dlerror()) != NULL)  {
+		return 1;
+	}
+	*(selevel_t **) (&setrans_selevelbysename) = dlsym(handle, "setrans_getselevelbysename");
+	if ((error = dlerror()) != NULL)  {
+		return 1;
+	}
+	return 0;
+}
+
+/* Get Security Level via internal Name */
+selevel_t *getselevelbyname( const char* name) {
+	if (getlibsetrans()) return NULL;
+	return (*setrans_selevelbyname)(name);
+}
+
+/* Get Security Level via external Name */
+selevel_t *getselevelbysename( const char* sename) {
+	if (getlibsetrans()) return NULL;
+	return (*setrans_selevelbysename)(sename);
+}
+
+/* Function used to translate a security context into external representation */
+extern char *setransconlevel(const security_context_t scon) {
+	char *rcon;
+	context_t con=context_new(scon);
+	selevel_t *level;
+	if (!con) 
+		return NULL;
+	level=getselevelbyname(context_range_get(con));
+	if (level) {
+		context_range_set(con, level->sename);
+		rcon=strdup(context_str(con));
+		freeselevel(level);
+	} else {
+		rcon=strdup(scon);
+	}
+	context_free(con);
+	return rcon;
+}

[-- Attachment #3: libsetrans-0.1.0-1.src.rpm --]
[-- Type: application/x-rpm, Size: 12953 bytes --]

Re: Category Translation patch for MCS/MLS Policy

[Casey Schaufler]

--- Daniel J Walsh <Dan-Walsh@comcast.net> wrote:


> Comments?

In the Unix MLS systems we found that
allowing whitespace in label names was
a bad idea. We also found that aliases
(e.g. TS for TopSecret, secret for Secret)
are absolutely necessary. I will not
participate in the case sensitive/insensitive
debate, but y'all should have it over
with. Then there's my favorite issue,
that of whether a user cleared only to
Secret can see the lable names for TopSecret.

You may not chose to address all of these
issues, but you should be ready to
explain why they don't matter as you will
be asked.



Casey Schaufler
casey@schaufler-ca.com

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
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: Category Translation patch for MCS/MLS Policy

[Joshua Brindle]

Casey Schaufler wrote:

>--- Daniel J Walsh <Dan-Walsh@comcast.net> wrote:
>
>
>  
>
>>Comments?
>>    
>>
>
>In the Unix MLS systems we found that
>allowing whitespace in label names was
>a bad idea.
>
i thought that was a bad idea too.

> We also found that aliases
>(e.g. TS for TopSecret, secret for Secret)
>are absolutely necessary. I will not
>participate in the case sensitive/insensitive
>debate, but y'all should have it over
>with. Then there's my favorite issue,
>that of whether a user cleared only to
>Secret can see the lable names for TopSecret.
>
>  
>
My impression was that the caching daemon (assuming we have one) or else 
the resolver would act as an userspace object manager to prevent labels 
from inappropriatly being disclosed.

>You may not chose to address all of these
>issues, but you should be ready to
>explain why they don't matter as you will
>be asked.
>
>  
>
I think most of us have at least been thinking about them.


--
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: Category Translation patch for MCS/MLS Policy

[Darrel Goeddel]

Daniel J Walsh wrote:
> I have written up a patch for libselinux to implement two functions, to 
> translate the security level.
> 
> getselevelbyname
> getselevelbysename
> setransconlevel
> 
> These functions try to dlopen a libsetrans and call the equivalent 
> functions in this library.
> Currently the patch only changes the *getfilecon function calls use 
> these translations.
> I have also attached a libsetrans-0.1.0-src.rpm  which would be the 
> translation library for MCS.
> 
> I am not sure if a similar library was proposed by TCS or not,  I can 
> not find it.  This is a lot simpler than
> what Ivan proposed last week.
> Manipulation of securitylevel is to be done by the provider of the 
> translation library (setrans).  So that a MLS environment
> can use the Mitre library to translate, while MCS can use much simpler 
> algorithms.
...
> 
> Comments?
> Did I reimplement something that others already implemented?  Is this 
> what people expect?
> 

We at TCS have tried several approaches to address context translations to a "human
readable" form from within libselinux.  Attached is our latest incarnation of the
translation framework.  We have been using this for a while without problems so it
should be fairly stable.  I have shared this with some folks (I believe that I included
you, sorry I did not) to show where we were and get initial feedback before bringing
it to the list (just trying to minimize my public beatdown ;)).  Below is a brief
description of what are doing and a few of my comments/questions from before.  As far
as the question about finding the library - I like libsetrans.so.  We can then make
that a link to any lib which supports the proper interfaces.  I have briefly looked
over your patch and it seems to be a subset of our work (and I'm still not sure ours
is complete).

Here is a brief description of what we are currently doing for context
translations:

- When libselinux initializes, it looks for a translation library on the system.
 If this library is found, it will initialize that library and make a note that
 translations should be performed.  Otherwise, life goes on as before.

- The translations are performed in the routines that receive/return contexts
 from the user.  We have provided extra interfaces (such as getfilecon_raw for
 getfilecon) that will skip translations even if the translation library is
 present on the system.

This method provides a nearly seamless transition for current applications to
take advantage of the translation facility because it hooks into the currently
used interfaces.  The extra interface are provided for developers that wish to
bypass the translations in cases where they are assured that the contexts will
never be presented to the users (there are a few cases of this in the library
itself, such as checkPasswdAccess and rpm_execcon).

This also makes the translation layer very flexible.  The translation library
only needs to have three interface available to libselinux
(init_context_translations, translate_context, and untranslate_context).  The code
can perform the translations however it wants (it should be able to reverse the
translation though).  This includes freedom to use a network based translator where
the library is simply a communications mechanism to the translation daemon.  I'm
reluctant to impose a communication mechanism with a translation daemon into
libselinux itself...

There are some outstanding questions that I have regarding this implementation.

- How do we find the translation library?  It is currently hard coded in libselinux.
  Putting it in a config file has its own issues because every user of libselinux
  will need to be able to read that config.  I'm liking hard coding a name into
  libselinux and using a symlink to get to the real lib because traversing symlinks
  to get to libraries is already handled by the policy.
        Something like /lib/libseltrans -> /lib/libXXX.so

- What should all be stored in translated form?  Certain configuration files will
  most likely want to be kept in the raw form to allow portability across
  installations (just like the policy).  Other files may want to use the translated
  form because that is what will make the most sense to the users.  I have put in
  a safety mechanism in the translation hooks that will allow send back the current
  form of the context if a translation fails.  This allows an application to read in
  a raw or a translated context from a config file and use that context with the
  libselinux interfaces.  I was trying to be more strict about that, but I just
  couldn't get everything working without modding apps that I did not want to touch.

- There are possibly some more translation points that should be added.  For instance,
  I was going put translations into the uavc, but I didn't have time...  And there may
  have been some things added to the lib that I missed putting translations in.

- I made all of the "regular" functions call the "raw" functions.  This could be
  optimized for a lot of cases (the setfilecon functions could call setxattr directly
  instead of calling it through setfilecon_raw), but those are trivial changes.

I welcome questions and comments and patches, etc.  I'm interested to hear what people
think about the approach in general.

-- 

Darrel

--
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: Category Translation patch for MCS/MLS Policy

[Darrel Goeddel]

Darrel Goeddel wrote:
> Attached is our latest incarnation of the translation framework.

Since I hit send before I actually attached the patch...  The patch
can be found at:

http://home.insightbb.com/~dgoeddel/translation.patch

Sorry about that.

-- 

Darrel

--
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: Category Translation patch for MCS/MLS Policy

[Daniel J Walsh]

Darrel Goeddel wrote:

> Darrel Goeddel wrote:
>
>> Attached is our latest incarnation of the translation framework.
>
>
> Since I hit send before I actually attached the patch...  The patch
> can be found at:
>
> http://home.insightbb.com/~dgoeddel/translation.patch
>
> Sorry about that.
>
Ok I will take a look at it. 

One thing I also want to think about is a mechanism to prevent 
translation for certain apps.  One thing we are thinking about for MCS 
is to allow an file to be in multiple categories.  So a c1-c3 
translation might look like

"MedicalRecords,MassGeneral,Cancer"
or
"CompanyConfidential,IBMNonDisclosure5"

So we would want files to show this, but if I do a ps -eZ command I 
don't want "System High" processes to translate it.
So does MLS ps command translate?  Or does MCS have to add the concept 
of "system high"?

-- 



--
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: Category Translation patch for MCS/MLS Policy

[Stephen Smalley]

On Wed, 2005-08-10 at 07:30 -0400, Daniel J Walsh wrote:
> Ok I will take a look at it. 
> 
> One thing I also want to think about is a mechanism to prevent 
> translation for certain apps.  One thing we are thinking about for MCS 
> is to allow an file to be in multiple categories.  So a c1-c3 
> translation might look like
> 
> "MedicalRecords,MassGeneral,Cancer"
> or
> "CompanyConfidential,IBMNonDisclosure5"
> 
> So we would want files to show this, but if I do a ps -eZ command I 
> don't want "System High" processes to translate it.
> So does MLS ps command translate?  Or does MCS have to add the concept 
> of "system high"?

IIRC, at present, procps doesn't use libselinux at all; procps directly
reads /proc/pid/attr/current and displays that value, since procps
already deals directly with /proc/pid entries and the maintainer
preferred to avoid a dependency of procps on libselinux (but was willing
to accept a dlopen of libselinux if we were to create such a patch, as
long as procps continues to work in the absence of libselinux).  Hence,
without further changes, procps won't perform any translation at all.

-- 
Stephen Smalley
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: Category Translation patch for MCS/MLS Policy

[Casey Schaufler]

--- Daniel J Walsh <dwalsh@redhat.com> wrote:

> One thing we are
> thinking about for MCS 
> is to allow an file to be in multiple categories.

Do you mean something different from the B&L
notion of multiple categories? Bell and LePadula,
as we all know, would allow a file to be marked
with multiple categories, but the accessing
process would have to have all of the said
categories for success. 

> So a c1-c3 
> translation might look like
> 
> "MedicalRecords,MassGeneral,Cancer"
> or
> "CompanyConfidential,IBMNonDisclosure5"
> 
> So we would want files to show this, but if I do a
> ps -eZ command I 
> don't want "System High" processes to translate it.

Why's that?

> So does MLS ps command translate?

If you're asking what I think you're asking
the answer is yes.

> Or does MCS have to add the concept
> of "system high"?

Not strictly. You could enumerate all categories,
but system high is much simpler, and you can
probably steal^H^H^H^Hhare more of the MLS code
that way. You might want to come up with a name
that's less threatening, perhaps "allcats", or
"star".


Casey Schaufler
casey@schaufler-ca.com


		
____________________________________________________
Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 

--
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: Category Translation patch for MCS/MLS Policy

[Colin Walters]

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

On Fri, 2005-08-05 at 12:02 -0400, Daniel J Walsh wrote:
> I have written up a patch for libselinux to implement two functions, to 
> translate the security level.

To namespace these a bit more strongly (and make them easier to read),
perhaps something like:

> getselevelbyname

selinux_get_level_by_name

> getselevelbysename

selinux_get_level_by_sename  (there may be a better name here, not sure)

> setransconlevel

selinux_translate_level

> typedef struct selevel {

Perhaps struct selinux_category/selinux_category_t?



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: Category Translation patch for MCS/MLS Policy

[Chad Hanson]

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


Attached is a patch to dlopen libselinux from procps and call getpidcon.
This patch is relative to procps-3.2.5-6.3 (from Fedora Updates).

-Chad

Stephen Smalley wrote:

> 
> IIRC, at present, procps doesn't use libselinux at all; procps directly
> reads /proc/pid/attr/current and displays that value, since procps
> already deals directly with /proc/pid entries and the maintainer
> preferred to avoid a dependency of procps on libselinux (but was willing
> to accept a dlopen of libselinux if we were to create such a patch, as
> long as procps continues to work in the absence of libselinux).  Hence,
> without further changes, procps won't perform any translation at all.
> 
> -- 
> Stephen Smalley
> National Security Agency
>  


[-- Attachment #2: procps-3.2.5-libselinux.patch --]
[-- Type: application/octet-stream, Size: 2406 bytes --]

diff -Nur procps-3.2.5.orig/ps/module.mk procps-3.2.5/ps/module.mk
--- procps-3.2.5.orig/ps/module.mk	2004-07-14 22:20:06.000000000 +0000
+++ procps-3.2.5/ps/module.mk	2005-05-09 19:46:22.000000000 +0000
@@ -20,7 +20,7 @@
 TARFILES += $(PSSRC) $(addprefix ps/,$(PS_X))
 
 ps/ps: $(PSOBJ) $(LIBPROC)
-	$(CC) $(ALL_CFLAGS) $(ALL_LDFLAGS) -o $@ $^
+	$(CC) $(ALL_CFLAGS) $(ALL_LDFLAGS) -o $@ $^ -ldl
 
 # This just adds the stacktrace code
 ps/debug: $(PSOBJ) stacktrace.o $(LIBPROC)
diff -Nur procps-3.2.5.orig/ps/output.c procps-3.2.5/ps/output.c
--- procps-3.2.5.orig/ps/output.c	2005-01-14 19:06:19.000000000 +0000
+++ procps-3.2.5/ps/output.c	2005-08-10 20:54:47.000000000 +0000
@@ -53,6 +53,7 @@
 #include <sys/mman.h>
 #include <time.h>
 #include <unistd.h>
+#include <dlfcn.h>
 
 #include "../proc/readproc.h"
 #include "../proc/sysinfo.h"
@@ -1094,31 +1095,34 @@
 
 // move the bulk of this to libproc sometime
 static int pr_context(char *restrict const outbuf, const proc_t *restrict const pp){
-  char filename[48];
+  static int (*ps_getpidcon)(pid_t pid, char **context) = 0;
+  static int tried_load = 0;
   size_t len;
-  ssize_t num_read;
-  int fd;
+  char *context;
 
-// wchan file is suitable for testing
-//snprintf(filename, sizeof filename, "/proc/%d/wchan", pp->tgid);
-snprintf(filename, sizeof filename, "/proc/%d/attr/current", pp->tgid);
-
-  fd = open(filename, O_RDONLY, 0);
-  if(likely(fd==-1)) goto fail;
-  num_read = read(fd, outbuf, 666);
-  close(fd);
-  if(unlikely(num_read<=0)) goto fail;
-  outbuf[num_read] = '\0';
-
-  len = 0;
-  while(outbuf[len]>' ' && outbuf[len]<='~') len++;
-  outbuf[len] = '\0';
-  if(len) return len;
-
-fail:
-  outbuf[0] = '-';
-  outbuf[1] = '\0';
-  return 1;
+  if(!ps_getpidcon && !tried_load){
+    void *handle = dlopen("libselinux.so.1", RTLD_NOW);
+    if(handle){
+      dlerror();
+      ps_getpidcon = dlsym(handle, "getpidcon");
+      if(dlerror())
+        ps_getpidcon = 0;
+    }
+    tried_load++;
+  }
+  if(ps_getpidcon && !ps_getpidcon(pp->tgid, &context)){
+    size_t max_len = OUTBUF_SIZE-1;
+    len = strlen(context);
+    if(len > max_len) len = max_len;
+    memcpy(outbuf, context, len);
+    outbuf[len] = '\0';
+    free(context);
+  }else{
+    outbuf[0] = '-';
+    outbuf[1] = '\0';
+    len = 1;
+  }
+  return len;
 }
 
 

RE: Category Translation patch for MCS/MLS Policy

[Stephen Smalley]

On Mon, 2005-08-15 at 16:35 -0400, Chad Hanson wrote:
> Attached is a patch to dlopen libselinux from procps and call getpidcon.
> This patch is relative to procps-3.2.5-6.3 (from Fedora Updates).

Have you tried running this patch by the upstream procps maintainer?
He may want some of this moved into libproc, and he may want to retain
the legal character checks.
  
-- 
Stephen Smalley
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.