X policy classes

X policy classes

[Joshua Brindle]

We noticed today that the SE-X policy classes have been merged into the 
sf.net cvs policy. Is there an ETA on when those will be merged into the 
kernel headers?

The reason I ask is because we added the pax class in Gentoo policy and 
kernels, now the ordering becomes an issue because with our current 
kernels (with pax support included) the policy flask/access_vectors 
ordering would have to have pax and then X classes but that would 
prevent a user from using a vanilla kernel which has the X classes in 
the headers.

We'll probably go ahead and add the X classes to our kernel headers and 
pax below them so that both vanilla and gentoo kernels would be able to 
load the same policy but we'll need to make changes to our policy and 
would like to know when we can expect the headers to be changed.

Another idea might be to add the pax class to the standard access_vector 
  file but I'm not sure how receptive that would be since afaik we are 
the only ones using it.

Joshua Brindle


--
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: X policy classes

[Stephen Smalley]

On Fri, 2004-05-14 at 02:19, Joshua Brindle wrote:
> We noticed today that the SE-X policy classes have been merged into the 
> sf.net cvs policy. Is there an ETA on when those will be merged into the 
> kernel headers?

Mea culpa.  I planned on waiting until we had an actual update that
affected the kernel code, e.g. the new netlink classes and permissions
under development by James Morris.  Also, there is a planned overhaul
for the kernel access vectors at some point to prune obsolete
permissions, possibly re-organize the remaining permissions more
sensibly, and deal with known gaps (e.g. we actually do need an execute
permission for packet sockets to deal with mmap'd packet sockets).  The
kernel doesn't need the definitions for the SE-X classes and
permissions, although it is true that the classes do affect any
subsequently defined classes (so this will affect James' netlink
classes; they'll need to be shifted unless we are willing to perturb the
values of the X classes).

> Another idea might be to add the pax class to the standard access_vector 
>   file but I'm not sure how receptive that would be since afaik we are 
> the only ones using it.

We should likely go ahead and merge your pax class and access vector
definition to avoid future changes to its value, as a running SELinux
kernel won't accept a policy reload that changes an existing class value
(since existing code may be using the definition).  Send a current patch
for policy/flask/*.

-- 
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: X policy classes

[Joshua Brindle]

Stephen Smalley wrote:

>On Fri, 2004-05-14 at 02:19, Joshua Brindle wrote:
>  
>
>>We noticed today that the SE-X policy classes have been merged into the 
>>sf.net cvs policy. Is there an ETA on when those will be merged into the 
>>kernel headers?
>>    
>>
>
>Mea culpa.  I planned on waiting until we had an actual update that
>affected the kernel code, e.g. the new netlink classes and permissions
>under development by James Morris.  Also, there is a planned overhaul
>for the kernel access vectors at some point to prune obsolete
>permissions, possibly re-organize the remaining permissions more
>sensibly, and deal with known gaps (e.g. we actually do need an execute
>permission for packet sockets to deal with mmap'd packet sockets).  The
>kernel doesn't need the definitions for the SE-X classes and
>permissions, although it is true that the classes do affect any
>subsequently defined classes (so this will affect James' netlink
>classes; they'll need to be shifted unless we are willing to perturb the
>values of the X classes).
>
>  
>
>>Another idea might be to add the pax class to the standard access_vector 
>>  file but I'm not sure how receptive that would be since afaik we are 
>>the only ones using it.
>>    
>>
>
>We should likely go ahead and merge your pax class and access vector
>definition to avoid future changes to its value, as a running SELinux
>kernel won't accept a policy reload that changes an existing class value
>(since existing code may be using the definition).  Send a current patch
>for policy/flask/*.
>
>  
>
This should be against the latest cvs, thanks for merging this

--- access_vectors.orig 2004-05-13 20:15:15.214145728 -0500
+++ access_vectors      2004-05-13 12:37:39.315076824 -0500
@@ -357,6 +357,20 @@
 }
 
 #
+# Define the access vector interpretation for controlling
+# PaX flags
+#
+class pax
+{
+        pageexec        # Paging based non-executable pages
+        emutramp        # Emulate trampolines
+        mprotect        # Restrict mprotect()
+        randmmap        # Randomize mmap() base
+        randexec        # Randomize ET_EXEC base
+        segmexec        # Segmentation based non-executable pages
+}
+
+#
 # SE-X Windows stuff
 #
 class drawable
--- security_classes.orig       2004-05-13 20:15:19.898433608 -0500
+++ security_classes    2004-05-13 12:37:47.489834072 -0500
@@ -47,6 +47,9 @@
 # passwd/chfn/chsh
 class passwd
 
+# pax flags
+class pax
+
 # SE-X Windows stuff
 class drawable
 class window

--
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: X policy classes

[Stephen Smalley]

On Fri, 2004-05-14 at 13:26, Joshua Brindle wrote:
> --- security_classes.orig       2004-05-13 20:15:19.898433608 -0500
> +++ security_classes    2004-05-13 12:37:47.489834072 -0500
> @@ -47,6 +47,9 @@
>  # passwd/chfn/chsh
>  class passwd
>  
> +# pax flags
> +class pax
> +
>  # SE-X Windows stuff
>  class drawable
>  class window
> 

Hmmm...applying that diff now will perturb the values of the X window
classes, requiring regeneration of the libselinux headers that went out
in the release we just made and requiring a rebuild of any modified X
servers upon a migration from libselinux-1.12 to any newer version.  How
much trouble is it for you to relocate the pax definition after the X
classes and migrate your users?

-- 
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: X policy classes

[Chris PeBenito]

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

On Fri, 2004-05-14 at 12:47, Stephen Smalley wrote:
> Hmmm...applying that diff now will perturb the values of the X window
> classes, requiring regeneration of the libselinux headers that went out
> in the release we just made and requiring a rebuild of any modified X
> servers upon a migration from libselinux-1.12 to any newer version.  How
> much trouble is it for you to relocate the pax definition after the X
> classes and migrate your users?

Yeah, we can just move the PaX stuff after the X classes.  We won't be
releasing a policy with the new X classes for a while anyway.

One thing I noticed was that when I regenerated the headers from the
policy flask dir, there were several differences between those, and the
ones that are in the mainline kernel's security/selinux/include
directory.  I'm not referring to the new devnull stuff, the SE-X, or our
PaX stuff, but in the current classes.  I came up with:

 /etc/security/selinux/src/policy/flask/av_perm_to_string.h     |    7
 /etc/security/selinux/src/policy/flask/av_permissions.h        |  467 +++++-----
 /etc/security/selinux/src/policy/flask/flask.h                 |    3
 /etc/security/selinux/src/policy/flask/initial_sid_to_string.h |    1
 4 files changed, 242 insertions(+), 236 deletions(-)

Wouldn't these mismatches cause problems?

-- 
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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: X policy classes

[Stephen Smalley]

On Fri, 2004-05-14 at 15:00, Chris PeBenito wrote:
> One thing I noticed was that when I regenerated the headers from the
> policy flask dir, there were several differences between those, and the
> ones that are in the mainline kernel's security/selinux/include
> directory.  I'm not referring to the new devnull stuff, the SE-X, or our
> PaX stuff, but in the current classes.  I came up with:
> 
>  /etc/security/selinux/src/policy/flask/av_perm_to_string.h     |    7
>  /etc/security/selinux/src/policy/flask/av_permissions.h        |  467 +++++-----
>  /etc/security/selinux/src/policy/flask/flask.h                 |    3
>  /etc/security/selinux/src/policy/flask/initial_sid_to_string.h |    1
>  4 files changed, 242 insertions(+), 236 deletions(-)
> 
> Wouldn't these mismatches cause problems?

If you look at the diffs, you should see that it is just an ordering
issue, not a change in actual values.  The current scripts are just
walking a hash and emitting the definitions, so the order isn't
guaranteed to be stable.  Someone should likely change the scripts to
avoid spurious diffs.

-- 
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: X policy classes

[Stephen Smalley]

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

On Fri, 2004-05-14 at 15:08, Stephen Smalley wrote:
> If you look at the diffs, you should see that it is just an ordering
> issue, not a change in actual values.  The current scripts are just
> walking a hash and emitting the definitions, so the order isn't
> guaranteed to be stable.  Someone should likely change the scripts to
> avoid spurious diffs.

I think that this patch will ensure a stable order for the
av_permissions.h definitions.  Naturally, it will yield a large diff for
the first time we regenerate headers using it, but subsequent
regeneration will hopefully have smaller diffs.  Look sane?

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

[-- Attachment #2: flask-sort.patch --]
[-- Type: text/x-patch, Size: 1793 bytes --]

Index: policy/flask/mkaccess_vector.sh
===================================================================
RCS file: /nfshome/pal/CVS/selinux-usr/policy/flask/mkaccess_vector.sh,v
retrieving revision 1.4
diff -u -r1.4 mkaccess_vector.sh
--- policy/flask/mkaccess_vector.sh	17 Jul 2003 11:44:34 -0000	1.4
+++ policy/flask/mkaccess_vector.sh	26 May 2004 15:30:40 -0000
@@ -123,17 +123,30 @@
 				split(combined,separate, SUBSEP);
 				if (separate[1] == inherits)
 				{
-					printf("#define %s__%s", toupper(tclass), toupper(separate[2])) > outfile; 
-					spaces = 40 - (length(separate[2]) + length(tclass));
-					if (spaces < 1)
-					      spaces = 1;
-					for (i = 0; i < spaces; i++) 
-						printf(" ") > outfile; 
-					printf("0x%08xUL\n", common_perms[combined]) > outfile; 
+					inherited_perms[common_perms[combined]] = separate[2];
 				}
 			}
+
+                        j = 1;
+                        for (i in inherited_perms) {
+                            ind[j] = i + 0;
+                            j++;
+                        }
+                        n = asort(ind);
+			for (i = 1; i <= n; i++) {
+				perm = inherited_perms[ind[i]];
+				printf("#define %s__%s", toupper(tclass), toupper(perm)) > outfile; 
+				spaces = 40 - (length(perm) + length(tclass));
+				if (spaces < 1)
+				      spaces = 1;
+				for (j = 0; j < spaces; j++) 
+					printf(" ") > outfile; 
+				printf("0x%08xUL\n", ind[i]) > outfile; 
+			}
 			printf("\n") > outfile;
-	
+                        for (i in ind) delete ind[i];
+                        for (i in inherited_perms) delete inherited_perms[i];
+
 			printf("   { SECCLASS_%s, common_%s_perm_to_string, 0x%08xUL },\n", toupper(tclass), inherits, permission) > inheritfile; 
 
 			nextstate = "CLASS_OR_CLASS-OPENBRACKET";

Re: X policy classes

[Stephen Smalley]

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

On Wed, 2004-05-26 at 11:35, Stephen Smalley wrote:
> I think that this patch will ensure a stable order for the
> av_permissions.h definitions.  Naturally, it will yield a large diff for
> the first time we regenerate headers using it, but subsequent
> regeneration will hopefully have smaller diffs.  Look sane?

And the resulting diff for the regenerated headers.  Note that you can
compare by sorting the pre-patched and patched headers and diffing the
sorted files to see that no unexpected changes occurred.

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

[-- Attachment #2: selinux-headers.patch.bz2 --]
[-- Type: application/x-bzip, Size: 4720 bytes --]

Re: X policy classes

[Joshua Brindle]

That is fine, we'll just need warning before those classes are put into 
the mainline kernel so that our users can be sure to have upgraded 
policies. Thanks again.

Joshua Brindle

Stephen Smalley wrote:

>On Fri, 2004-05-14 at 13:26, Joshua Brindle wrote:
>  
>
>>--- security_classes.orig       2004-05-13 20:15:19.898433608 -0500
>>+++ security_classes    2004-05-13 12:37:47.489834072 -0500
>>@@ -47,6 +47,9 @@
>> # passwd/chfn/chsh
>> class passwd
>> 
>>+# pax flags
>>+class pax
>>+
>> # SE-X Windows stuff
>> class drawable
>> class window
>>
>>    
>>
>
>Hmmm...applying that diff now will perturb the values of the X window
>classes, requiring regeneration of the libselinux headers that went out
>in the release we just made and requiring a rebuild of any modified X
>servers upon a migration from libselinux-1.12 to any newer version.  How
>much trouble is it for you to relocate the pax definition after the X
>classes and migrate your users?
>
>  
>


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