2008-09-25 18:45:37

by Daniel Walsh

[permalink] [raw]
Subject: [refpolicy] mls.patch

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

http://people.fedoraproject.org/~dwalsh/SELinux/F10/mls.patch

Joe this is the patch I have off of current reference policy. Is this
correct or should I use reference policy mls?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkjb3FEACgkQrlYvE4MpobN1xACgvaEBGk/voTESvAuYqyO2s+5g
DWYAoObTfnusOs+FcaJIc7PeZQl9W/KR
=y3BJ
-----END PGP SIGNATURE-----


2008-09-26 00:45:34

by joe

[permalink] [raw]
Subject: [refpolicy] mls.patch


On Sep 25, 2008, at 1:45 PM, Daniel J Walsh wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> http://people.fedoraproject.org/~dwalsh/SELinux/F10/mls.patch
>
> Joe this is the patch I have off of current reference policy. Is
> this
> correct or should I use reference policy mls?

It was my transcription of Eamon's verbal how-to and it works so far.
It may not be the final word on the topic as we are just starting to
test X in mls enforcing. Eamon might be able to loosen it up some
safely.

joe

2008-09-26 15:26:58

by Eamon Walsh

[permalink] [raw]
Subject: [refpolicy] mls.patch

Joe Nall wrote:
> On Sep 25, 2008, at 1:45 PM, Daniel J Walsh wrote:
>
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> http://people.fedoraproject.org/~dwalsh/SELinux/F10/mls.patch
>>
>> Joe this is the patch I have off of current reference policy. Is
>> this
>> correct or should I use reference policy mls?
>>
>
> It was my transcription of Eamon's verbal how-to and it works so far.
> It may not be the final word on the topic as we are just starting to
> test X in mls enforcing. Eamon might be able to loosen it up some
> safely.
>
> joe
>
>

Also, here is a combined version of the range transition patches I sent
earlier. These were in response to the socket level and root window
level issued raised by Ted.

Index: policy/modules/services/xserver.if
===================================================================
--- policy/modules/services/xserver.if (revision 2819)
+++ policy/modules/services/xserver.if (working copy)
@@ -77,6 +77,9 @@
files_tmp_filetrans($1_xserver_t, $1_xserver_tmp_t, { file dir sock_file })

filetrans_pattern($1_xserver_t, xdm_xserver_tmp_t, $1_xserver_tmp_t, sock_file)
+ ifdef(`enable_mls',`
+ range_transition $1_xserver_t $1_xserver_tmp_t:sock_file s0 - mls_systemhigh;
+ ')

manage_dirs_pattern($1_xserver_t, $1_xserver_tmpfs_t, $1_xserver_tmpfs_t)
manage_files_pattern($1_xserver_t, $1_xserver_tmpfs_t, $1_xserver_tmpfs_t)
@@ -95,6 +98,9 @@

# Labeling rules for default windows and colormaps
type_transition $1_xserver_t $1_xserver_t:{ x_drawable x_colormap } $1_rootwindow_t;
+ ifdef(`enable_mls',`
+ range_transition $1_xserver_t $1_rootwindow_t:x_drawable s0 - mls_systemhigh;
+ ')

kernel_read_system_state($1_xserver_t)
kernel_read_device_sysctls($1_xserver_t)


--
Eamon Walsh <[email protected]>
National Security Agency

2008-10-06 15:07:30

by cpebenito

[permalink] [raw]
Subject: [refpolicy] mls.patch

On Thu, 2008-09-25 at 14:45 -0400, Daniel J Walsh wrote:
> http://people.fedoraproject.org/~dwalsh/SELinux/F10/mls.patch
>
> Joe this is the patch I have off of current reference policy. Is this
> correct or should I use reference policy mls?

This has a problem: It makes the xserver module required in the base
module.

--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

2008-10-06 15:19:06

by joe

[permalink] [raw]
Subject: [refpolicy] mls.patch


On Oct 6, 2008, at 10:07 AM, Christopher J. PeBenito wrote:

> On Thu, 2008-09-25 at 14:45 -0400, Daniel J Walsh wrote:
>> http://people.fedoraproject.org/~dwalsh/SELinux/F10/mls.patch
>>
>> Joe this is the patch I have off of current reference policy. Is
>> this
>> correct or should I use reference policy mls?
>
> This has a problem: It makes the xserver module required in the base
> module.

Due to the use of rootwindow_type?

Should a new attribute be added to mls.te and used here?

joe

2008-10-06 17:31:09

by cpebenito

[permalink] [raw]
Subject: [refpolicy] mls.patch

On Fri, 2008-09-26 at 11:26 -0400, Eamon Walsh wrote:
> Joe Nall wrote:
> > On Sep 25, 2008, at 1:45 PM, Daniel J Walsh wrote:
> >
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> http://people.fedoraproject.org/~dwalsh/SELinux/F10/mls.patch
> >>
> >> Joe this is the patch I have off of current reference policy. Is
> >> this
> >> correct or should I use reference policy mls?
> >>
> >
> > It was my transcription of Eamon's verbal how-to and it works so far.
> > It may not be the final word on the topic as we are just starting to
> > test X in mls enforcing. Eamon might be able to loosen it up some
> > safely.
> >
> > joe
> >
> >
>
> Also, here is a combined version of the range transition patches I sent
> earlier. These were in response to the socket level and root window
> level issued raised by Ted.

Merged.

> Index: policy/modules/services/xserver.if
> ===================================================================
> --- policy/modules/services/xserver.if (revision 2819)
> +++ policy/modules/services/xserver.if (working copy)
> @@ -77,6 +77,9 @@
> files_tmp_filetrans($1_xserver_t, $1_xserver_tmp_t, { file dir sock_file })
>
> filetrans_pattern($1_xserver_t, xdm_xserver_tmp_t, $1_xserver_tmp_t, sock_file)
> + ifdef(`enable_mls',`
> + range_transition $1_xserver_t $1_xserver_tmp_t:sock_file s0 - mls_systemhigh;
> + ')
>
> manage_dirs_pattern($1_xserver_t, $1_xserver_tmpfs_t, $1_xserver_tmpfs_t)
> manage_files_pattern($1_xserver_t, $1_xserver_tmpfs_t, $1_xserver_tmpfs_t)
> @@ -95,6 +98,9 @@
>
> # Labeling rules for default windows and colormaps
> type_transition $1_xserver_t $1_xserver_t:{ x_drawable x_colormap } $1_rootwindow_t;
> + ifdef(`enable_mls',`
> + range_transition $1_xserver_t $1_rootwindow_t:x_drawable s0 - mls_systemhigh;
> + ')
>
> kernel_read_system_state($1_xserver_t)
> kernel_read_device_sysctls($1_xserver_t)
>
>
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

2008-10-06 17:32:20

by Daniel Walsh

[permalink] [raw]
Subject: [refpolicy] mls.patch

Christopher J. PeBenito wrote:
> On Thu, 2008-09-25 at 14:45 -0400, Daniel J Walsh wrote:
>> http://people.fedoraproject.org/~dwalsh/SELinux/F10/mls.patch
>>
>> Joe this is the patch I have off of current reference policy. Is this
>> correct or should I use reference policy mls?
>
> This has a problem: It makes the xserver module required in the base
> module.
>
Should this constraint be moved to xserver.te then?

2008-10-06 18:08:28

by cpebenito

[permalink] [raw]
Subject: [refpolicy] mls.patch

On Mon, 2008-10-06 at 13:32 -0400, Daniel J Walsh wrote:
> Christopher J. PeBenito wrote:
> > On Thu, 2008-09-25 at 14:45 -0400, Daniel J Walsh wrote:
> >> http://people.fedoraproject.org/~dwalsh/SELinux/F10/mls.patch
> >>
> >> Joe this is the patch I have off of current reference policy. Is this
> >> correct or should I use reference policy mls?
> >
> > This has a problem: It makes the xserver module required in the base
> > module.
> >
> Should this constraint be moved to xserver.te then?

Unfortunately that won't work as constraints don't work in modules.

--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150

2008-10-06 18:12:43

by cpebenito

[permalink] [raw]
Subject: [refpolicy] mls.patch

On Mon, 2008-10-06 at 10:19 -0500, Joe Nall wrote:
> On Oct 6, 2008, at 10:07 AM, Christopher J. PeBenito wrote:
> > On Thu, 2008-09-25 at 14:45 -0400, Daniel J Walsh wrote:
> >> http://people.fedoraproject.org/~dwalsh/SELinux/F10/mls.patch
> >>
> >> Joe this is the patch I have off of current reference policy. Is
> >> this
> >> correct or should I use reference policy mls?
> >
> > This has a problem: It makes the xserver module required in the base
> > module.
>
> Due to the use of rootwindow_type?
>
> Should a new attribute be added to mls.te and used here?

I would make a mlsrootwindow attribute and apply it to types in the same
places that rootwindow_type are used, rather than trying to just have
one attribute.

--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150