What policy is the system running?

What policy is the system running?

[Daniel J Walsh]

We have been doing some work on sestatus and selinuxconfig type tools 
to  be able to tell us about the current running system. 
We have a problem in that we can not tell which policy is currently 
running on the system (strict, targeted, mls, ...)  It would be
usefull if there was a way to identify a name in policy.  Then if there 
was a way to ask the kernel what name it has loaded. 
One possible way we have thought about doing this is by defining a 
boolean for each policy that would define the policytype. 
So we could define a policytype_targeted boolean in targeted policy and 
a policytype_strict boolean in strict policy.
Then we could make scripts and programs smart enough to look for 
/selinux/booleans/policytype_* to determine it.
This is admittedly a hack but would solve our problem without having to 
modify the kernel.  One potential problem with this is
that the policy writers could define two policytype_ booleans.  Another 
problem is that there is no requirement to define a
boolean of this type.  

Other ideas that have been discussed is modifying load_policy and init 
to write /var/run/policytype or some such, but init runs
too early in the boot process to write to the local file system.

Adding a policyname type to policy, changin checkpolicy to require this 
field,  and then modifying the kernel to  provide this field
in the selinux file system, would probably be the ultimate solution. 

One other thing to think about; When we have loadable  policymodules, it 
would be nice to identify which modules are currently loaded, via a 
similar mechanism.

Ideas???

Dan

--
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: What policy is the system running?

[James Morris]

On Tue, 2 Nov 2004, Daniel J Walsh wrote:

> Ideas???

We could do an md5 checksum of the binary policy as it is written to 
/selinuxfs/load then export this via /selinux/policy_md5sum.

This would allow you to determine which policy is loaded.  Each binary 
policy module could be similarly checksummed.


- James
-- 
James Morris
<jmorris@redhat.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: What policy is the system running?

[Steve G]

>We could do an md5 checksum of the binary policy as it is written to 
>/selinuxfs/load then export this via /selinux/policy_md5sum.

I'm not sure I like this approach...they may have just recompiled a policy
(overwriting the one in memory) and have either no policy that matches or perhaps
multiple policies that match.

-Steve Grubb


		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.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: What policy is the system running?

[Steven Harp]

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

On Wednesday 03 November 2004 10:03 am, Steve G wrote:
> >We could do an md5 checksum of the binary policy as it is written to 
> >/selinuxfs/load then export this via /selinux/policy_md5sum.
> 
> I'm not sure I like this approach...they may have just recompiled a policy
> (overwriting the one in memory) and have either no policy that matches or perhaps
> multiple policies that match.

Agreed. The policyname approach alluded earlier would be more
useful.  Policy author gets to pick a name, version numbers etc,
supplemented by automatic information about when/where compiled.
This would convey the useful information for management.  Working with
a set of machines running various different policies under continuous
development, I can testify this sort of feature would really be
valued. I'd speculate this much would be easy to add to /selinux fs. 

Steve H


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQFBiRVVPcFX9H2zuSkRAm/+AJ4w5273zTrHRYhIa8NJaneIGu8dbgCgjrhp
s5NvovzYfUgTVV4GAah3F9c=
=BJPU
-----END PGP SIGNATURE-----



--
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: What policy is the system running?

[Karl MacMillan]

On Wed, 2004-11-03 at 08:03 -0800, Steve G wrote:
> >We could do an md5 checksum of the binary policy as it is written to 
> >/selinuxfs/load then export this via /selinux/policy_md5sum.
> 
> I'm not sure I like this approach...they may have just recompiled a policy
> (overwriting the one in memory) and have either no policy that matches or perhaps
> multiple policies that match.
> 

This would be case for setting boolean states on policy load, correct?

Karl

> -Steve Grubb
> 
> 
> 		
> __________________________________ 
> Do you Yahoo!? 
> Check out the new Yahoo! Front Page. 
> www.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.
-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.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: What policy is the system running?

[Steve G]

>This would be case for setting boolean states on policy load, correct?

I made a typo in my reply..I meant overwrite what's on disk. Sorry.

-Steve Grubb



__________________________________________________
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: What policy is the system running?

[Stephen Smalley]

On Wed, 2004-11-03 at 13:51, Steve G wrote:
> >This would be case for setting boolean states on policy load, correct?
> 
> I made a typo in my reply..I meant overwrite what's on disk. Sorry.

I think the in-memory modification of the policy for the boolean
settings is the larger concern, as it means that the binary policy seen
by the kernel may not match any file on disk, not even the one that was
"loaded".

-- 
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: What policy is the system running?

[Daniel J Walsh]

James suggests that we have a table on disk that references the checksum 
to a name.

So we could get the checksum from the kernel and then look up the name 
to display
to the user.  Could have Makefile and rpm update the policy whenever it 
is modified.

Dan

--
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: What policy is the system running?

[Stephen Smalley]

On Wed, 2004-11-03 at 17:55, Daniel J Walsh wrote:
> James suggests that we have a table on disk that references the checksum 
> to a name.
> 
> So we could get the checksum from the kernel and then look up the name 
> to display
> to the user.  Could have Makefile and rpm update the policy whenever it 
> is modified.

As I mentioned, I don't believe that this will work, because load_policy
is "patching" the binary policy in-memory to set the boolean values to
the locally configured settings prior to loading it into the kernel. 
Hence, any checksum computed by the kernel will not necessarily
correspond to the checksum of any binary policy file, not even the one
that was loaded.  You would have to update your checksum mapping not
only when the binary policy file was updated, but whenever a boolean
setting was changed.

-- 
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: What policy is the system running?

[Karl MacMillan]

On Tue, 2004-11-02 at 14:23 -0500, Daniel J Walsh wrote:
> We have been doing some work on sestatus and selinuxconfig type tools 
> to  be able to tell us about the current running system. 
> We have a problem in that we can not tell which policy is currently 
> running on the system (strict, targeted, mls, ...)  It would be
> usefull if there was a way to identify a name in policy.  Then if there 
> was a way to ask the kernel what name it has loaded. 
> One possible way we have thought about doing this is by defining a 
> boolean for each policy that would define the policytype. 
> So we could define a policytype_targeted boolean in targeted policy and 
> a policytype_strict boolean in strict policy.
> Then we could make scripts and programs smart enough to look for 
> /selinux/booleans/policytype_* to determine it.
> This is admittedly a hack but would solve our problem without having to 
> modify the kernel.  One potential problem with this is
> that the policy writers could define two policytype_ booleans.  Another 
> problem is that there is no requirement to define a
> boolean of this type.  
> 
> Other ideas that have been discussed is modifying load_policy and init 
> to write /var/run/policytype or some such, but init runs
> too early in the boot process to write to the local file system.
> 
> Adding a policyname type to policy, changin checkpolicy to require this 
> field,  and then modifying the kernel to  provide this field
> in the selinux file system, would probably be the ultimate solution. 
> 
> One other thing to think about; When we have loadable  policymodules, it 
> would be nice to identify which modules are currently loaded, via a 
> similar mechanism.
> 

The policy modules have a name defined in the policy language (which is
required). The "loaded" modules is a little harder. You can obtain a
list of installed modules in a similar manner to rpm, but when they are
loaded depends on when the kernel policy that has all of the modules
linked together is loaded. The kernel has no notion of modules, which is
nice because it required no changes to the kernel, but may present a
problem for you in this case.

Karl

> Ideas???
> 
> Dan
> 
> --
> 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.
-- 
Karl MacMillan
Tresys Technology
kmacmillan@tresys.com
http://www.tresys.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: What policy is the system running?

[Chris PeBenito]

[-- Attachment #1.1: Type: text/plain, Size: 846 bytes --]

On Tue, 2004-11-02 at 14:23 -0500, Daniel J Walsh wrote:
> We have been doing some work on sestatus and selinuxconfig type tools 
> to  be able to tell us about the current running system. 
> We have a problem in that we can not tell which policy is currently 
> running on the system (strict, targeted, mls, ...)

Since I've been trying out the MLS stuff, I cooked up a patch for
sestatus to display that the kernel is compiled with MLS.  I also put it
on the "disabled" output, for the case that someone accidentally
compiles a MLS kernel, and wonders why their policy won't load.

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer,
Hardened Gentoo Linux
Embedded Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243


[-- Attachment #1.2: sestatus-mls.diff --]
[-- Type: text/x-patch, Size: 704 bytes --]

Index: sestatus.c
===================================================================
RCS file: /var/cvsroot/gentoo-projects/hardened/policycoreutils-extra/src/sestatus.c,v
retrieving revision 1.21
diff -u -r1.21 sestatus.c
--- sestatus.c	27 Aug 2004 23:43:47 -0000	1.21
+++ sestatus.c	3 Nov 2004 01:17:30 -0000
@@ -201,10 +201,18 @@
 
 	switch(rc) {
 		case 1:
-			printf("enabled\n");
+			if(is_selinux_mls_enabled())
+				printf("enabled, MLS\n");
+			else
+				printf("enabled\n");
+
 			break;
 		case 0:
-			printf("disabled\n");
+			if(is_selinux_mls_enabled())
+				printf("disabled, MLS\n");
+			else
+				printf("disabled\n");
+
 			return 0;
 			break;
 		default:

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