odd policy behavior

odd policy behavior

[Xavier Toth]

I have an app that wasn't working in enforcing but there are no AVCs.
So I did 'semodule -DB' to see if there were any dontaudit denials and
restarted the app. The problem is that the app then ran fine. So I
tried load_policy which had no affect and 'semodule -B' which makes it
work. Any ideas what could be happening? I've verified with 'semodule
--list' that the module is loaded prior to doing the 'semodule -B'.

Ted

--
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: odd policy behavior

[Stephen Smalley]

On Tue, 2009-02-03 at 10:28 -0600, Xavier Toth wrote:
> I have an app that wasn't working in enforcing but there are no AVCs.
> So I did 'semodule -DB' to see if there were any dontaudit denials and
> restarted the app. The problem is that the app then ran fine. So I
> tried load_policy which had no affect and 'semodule -B' which makes it
> work. Any ideas what could be happening? I've verified with 'semodule
> --list' that the module is loaded prior to doing the 'semodule -B'.

- How was the app failing?
- Did you try running the app in permissive as well?
- Is this reproducible at all or are you unable to reproduce the
application failure now under any conditions?
- Did the app create/use any transient resources (temporary files,
system v ipc objects, etc) that could have prevented it from succeeding
on subsequent execution if they weren't properly cleaned up on prior
exit?

-- 
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: odd policy behavior

[Xavier Toth]

On Tue, Feb 3, 2009 at 10:38 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Tue, 2009-02-03 at 10:28 -0600, Xavier Toth wrote:
>> I have an app that wasn't working in enforcing but there are no AVCs.
>> So I did 'semodule -DB' to see if there were any dontaudit denials and
>> restarted the app. The problem is that the app then ran fine. So I
>> tried load_policy which had no affect and 'semodule -B' which makes it
>> work. Any ideas what could be happening? I've verified with 'semodule
>> --list' that the module is loaded prior to doing the 'semodule -B'.
>
> - How was the app failing?

This is our security banner app that draw a window across the top of
the screen with the users MLS range and with the appropriate
background color. When it fails there is just a window with a gray
background no text or color.

> - Did you try running the app in permissive as well?
> - Is this reproducible at all or are you unable to reproduce the
> application failure now under any conditions?
> - Did the app create/use any transient resources (temporary files,
> system v ipc objects, etc) that could have prevented it from succeeding
> on subsequent execution if they weren't properly cleaned up on prior
> exit?

After further investigation I found that a call to getseuserbyname for
the login user is returning the user name passed in and nothing for
the range which would be used in the banner. During our installation
we don't explicitly map this user to a SELinux user but our experience
has been that the when there is no mapping the user and range of the
'__default__' login are returned. Indeed once I rebuild policy this
appears to be what is happening. How rebuilding and reloading policy
would affect this is unclear.

>
> --
> 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: odd policy behavior

[Stephen Smalley]

On Tue, 2009-02-03 at 13:59 -0600, Xavier Toth wrote:
> On Tue, Feb 3, 2009 at 10:38 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > On Tue, 2009-02-03 at 10:28 -0600, Xavier Toth wrote:
> >> I have an app that wasn't working in enforcing but there are no AVCs.
> >> So I did 'semodule -DB' to see if there were any dontaudit denials and
> >> restarted the app. The problem is that the app then ran fine. So I
> >> tried load_policy which had no affect and 'semodule -B' which makes it
> >> work. Any ideas what could be happening? I've verified with 'semodule
> >> --list' that the module is loaded prior to doing the 'semodule -B'.
> >
> > - How was the app failing?
> 
> This is our security banner app that draw a window across the top of
> the screen with the users MLS range and with the appropriate
> background color. When it fails there is just a window with a gray
> background no text or color.
> 
> > - Did you try running the app in permissive as well?
> > - Is this reproducible at all or are you unable to reproduce the
> > application failure now under any conditions?
> > - Did the app create/use any transient resources (temporary files,
> > system v ipc objects, etc) that could have prevented it from succeeding
> > on subsequent execution if they weren't properly cleaned up on prior
> > exit?
> 
> After further investigation I found that a call to getseuserbyname for
> the login user is returning the user name passed in and nothing for
> the range which would be used in the banner. During our installation
> we don't explicitly map this user to a SELinux user but our experience
> has been that the when there is no mapping the user and range of the
> '__default__' login are returned. Indeed once I rebuild policy this
> appears to be what is happening. How rebuilding and reloading policy
> would affect this is unclear.

If the installed seusers file (i.e. /etc/selinux/$SELINUXTYPE/seusers)
did not exist originally or was unreadable (e.g. wrong context or mode),
then getseuserbyname() would behave the way you described.  Rebuilding
policy would have caused the regenerated seusers file to be installed,
possibly with different context or mode than the original state.

-- 
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: odd policy behavior

[Xavier Toth]

On Tue, Feb 3, 2009 at 3:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Tue, 2009-02-03 at 13:59 -0600, Xavier Toth wrote:
>> On Tue, Feb 3, 2009 at 10:38 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> > On Tue, 2009-02-03 at 10:28 -0600, Xavier Toth wrote:
>> >> I have an app that wasn't working in enforcing but there are no AVCs.
>> >> So I did 'semodule -DB' to see if there were any dontaudit denials and
>> >> restarted the app. The problem is that the app then ran fine. So I
>> >> tried load_policy which had no affect and 'semodule -B' which makes it
>> >> work. Any ideas what could be happening? I've verified with 'semodule
>> >> --list' that the module is loaded prior to doing the 'semodule -B'.
>> >
>> > - How was the app failing?
>>
>> This is our security banner app that draw a window across the top of
>> the screen with the users MLS range and with the appropriate
>> background color. When it fails there is just a window with a gray
>> background no text or color.
>>
>> > - Did you try running the app in permissive as well?
>> > - Is this reproducible at all or are you unable to reproduce the
>> > application failure now under any conditions?
>> > - Did the app create/use any transient resources (temporary files,
>> > system v ipc objects, etc) that could have prevented it from succeeding
>> > on subsequent execution if they weren't properly cleaned up on prior
>> > exit?
>>
>> After further investigation I found that a call to getseuserbyname for
>> the login user is returning the user name passed in and nothing for
>> the range which would be used in the banner. During our installation
>> we don't explicitly map this user to a SELinux user but our experience
>> has been that the when there is no mapping the user and range of the
>> '__default__' login are returned. Indeed once I rebuild policy this
>> appears to be what is happening. How rebuilding and reloading policy
>> would affect this is unclear.
>
> If the installed seusers file (i.e. /etc/selinux/$SELINUXTYPE/seusers)
> did not exist originally or was unreadable (e.g. wrong context or mode),
> then getseuserbyname() would behave the way you described.  Rebuilding
> policy would have caused the regenerated seusers file to be installed,
> possibly with different context or mode than the original state.
>
> --
> Stephen Smalley
> National Security Agency
>
>

You nailed it for some reason seusers is SystemHigh. Still
investigating ... Thanks

Ted

--
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: odd policy behavior

[Xavier Toth]

On Tue, Feb 3, 2009 at 3:49 PM, Xavier Toth <txtoth@gmail.com> wrote:
> On Tue, Feb 3, 2009 at 3:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>> On Tue, 2009-02-03 at 13:59 -0600, Xavier Toth wrote:
>>> On Tue, Feb 3, 2009 at 10:38 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>> > On Tue, 2009-02-03 at 10:28 -0600, Xavier Toth wrote:
>>> >> I have an app that wasn't working in enforcing but there are no AVCs.
>>> >> So I did 'semodule -DB' to see if there were any dontaudit denials and
>>> >> restarted the app. The problem is that the app then ran fine. So I
>>> >> tried load_policy which had no affect and 'semodule -B' which makes it
>>> >> work. Any ideas what could be happening? I've verified with 'semodule
>>> >> --list' that the module is loaded prior to doing the 'semodule -B'.
>>> >
>>> > - How was the app failing?
>>>
>>> This is our security banner app that draw a window across the top of
>>> the screen with the users MLS range and with the appropriate
>>> background color. When it fails there is just a window with a gray
>>> background no text or color.
>>>
>>> > - Did you try running the app in permissive as well?
>>> > - Is this reproducible at all or are you unable to reproduce the
>>> > application failure now under any conditions?
>>> > - Did the app create/use any transient resources (temporary files,
>>> > system v ipc objects, etc) that could have prevented it from succeeding
>>> > on subsequent execution if they weren't properly cleaned up on prior
>>> > exit?
>>>
>>> After further investigation I found that a call to getseuserbyname for
>>> the login user is returning the user name passed in and nothing for
>>> the range which would be used in the banner. During our installation
>>> we don't explicitly map this user to a SELinux user but our experience
>>> has been that the when there is no mapping the user and range of the
>>> '__default__' login are returned. Indeed once I rebuild policy this
>>> appears to be what is happening. How rebuilding and reloading policy
>>> would affect this is unclear.
>>
>> If the installed seusers file (i.e. /etc/selinux/$SELINUXTYPE/seusers)
>> did not exist originally or was unreadable (e.g. wrong context or mode),
>> then getseuserbyname() would behave the way you described.  Rebuilding
>> policy would have caused the regenerated seusers file to be installed,
>> possibly with different context or mode than the original state.
>>
>> --
>> Stephen Smalley
>> National Security Agency
>>
>>
>
> You nailed it for some reason seusers is SystemHigh. Still
> investigating ... Thanks
>
> Ted
>

The plot thickens. semodule -B causes seusers to be relabeled
SystemLow. restorecon /etc/selinux/mls/seusers causes the file to be
relabeled SystemHigh. Which is right?

Ted

--
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: odd policy behavior

[Stephen Smalley]

On Tue, 2009-02-03 at 16:31 -0600, Xavier Toth wrote:
> On Tue, Feb 3, 2009 at 3:49 PM, Xavier Toth <txtoth@gmail.com> wrote:
> > On Tue, Feb 3, 2009 at 3:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >> On Tue, 2009-02-03 at 13:59 -0600, Xavier Toth wrote:
> >>> On Tue, Feb 3, 2009 at 10:38 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >>> > On Tue, 2009-02-03 at 10:28 -0600, Xavier Toth wrote:
> >>> >> I have an app that wasn't working in enforcing but there are no AVCs.
> >>> >> So I did 'semodule -DB' to see if there were any dontaudit denials and
> >>> >> restarted the app. The problem is that the app then ran fine. So I
> >>> >> tried load_policy which had no affect and 'semodule -B' which makes it
> >>> >> work. Any ideas what could be happening? I've verified with 'semodule
> >>> >> --list' that the module is loaded prior to doing the 'semodule -B'.
> >>> >
> >>> > - How was the app failing?
> >>>
> >>> This is our security banner app that draw a window across the top of
> >>> the screen with the users MLS range and with the appropriate
> >>> background color. When it fails there is just a window with a gray
> >>> background no text or color.
> >>>
> >>> > - Did you try running the app in permissive as well?
> >>> > - Is this reproducible at all or are you unable to reproduce the
> >>> > application failure now under any conditions?
> >>> > - Did the app create/use any transient resources (temporary files,
> >>> > system v ipc objects, etc) that could have prevented it from succeeding
> >>> > on subsequent execution if they weren't properly cleaned up on prior
> >>> > exit?
> >>>
> >>> After further investigation I found that a call to getseuserbyname for
> >>> the login user is returning the user name passed in and nothing for
> >>> the range which would be used in the banner. During our installation
> >>> we don't explicitly map this user to a SELinux user but our experience
> >>> has been that the when there is no mapping the user and range of the
> >>> '__default__' login are returned. Indeed once I rebuild policy this
> >>> appears to be what is happening. How rebuilding and reloading policy
> >>> would affect this is unclear.
> >>
> >> If the installed seusers file (i.e. /etc/selinux/$SELINUXTYPE/seusers)
> >> did not exist originally or was unreadable (e.g. wrong context or mode),
> >> then getseuserbyname() would behave the way you described.  Rebuilding
> >> policy would have caused the regenerated seusers file to be installed,
> >> possibly with different context or mode than the original state.
> >>
> >> --
> >> Stephen Smalley
> >> National Security Agency
> >>
> >>
> >
> > You nailed it for some reason seusers is SystemHigh. Still
> > investigating ... Thanks
> >
> > Ted
> >
> 
> The plot thickens. semodule -B causes seusers to be relabeled
> SystemLow. restorecon /etc/selinux/mls/seusers causes the file to be
> relabeled SystemHigh. Which is right?

I don't think that semodule/libsemanage explicitly set the context of
files they create, so they would just follow the default policy behavior
(in this case, inheriting the level of the creating process and the type
of the parent directory).

restorecon just applies whatever the file_contexts configuration
specifies, which appears to be SystemHigh in the mls policy.  I'm not
sure if that is truly justified.

-- 
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: odd policy behavior

[Daniel J Walsh]

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

Stephen Smalley wrote:
> On Tue, 2009-02-03 at 16:31 -0600, Xavier Toth wrote:
>> On Tue, Feb 3, 2009 at 3:49 PM, Xavier Toth <txtoth@gmail.com> wrote:
>>> On Tue, Feb 3, 2009 at 3:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>> On Tue, 2009-02-03 at 13:59 -0600, Xavier Toth wrote:
>>>>> On Tue, Feb 3, 2009 at 10:38 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>>>> On Tue, 2009-02-03 at 10:28 -0600, Xavier Toth wrote:
>>>>>>> I have an app that wasn't working in enforcing but there are no AVCs.
>>>>>>> So I did 'semodule -DB' to see if there were any dontaudit denials and
>>>>>>> restarted the app. The problem is that the app then ran fine. So I
>>>>>>> tried load_policy which had no affect and 'semodule -B' which makes it
>>>>>>> work. Any ideas what could be happening? I've verified with 'semodule
>>>>>>> --list' that the module is loaded prior to doing the 'semodule -B'.
>>>>>> - How was the app failing?
>>>>> This is our security banner app that draw a window across the top of
>>>>> the screen with the users MLS range and with the appropriate
>>>>> background color. When it fails there is just a window with a gray
>>>>> background no text or color.
>>>>>
>>>>>> - Did you try running the app in permissive as well?
>>>>>> - Is this reproducible at all or are you unable to reproduce the
>>>>>> application failure now under any conditions?
>>>>>> - Did the app create/use any transient resources (temporary files,
>>>>>> system v ipc objects, etc) that could have prevented it from succeeding
>>>>>> on subsequent execution if they weren't properly cleaned up on prior
>>>>>> exit?
>>>>> After further investigation I found that a call to getseuserbyname for
>>>>> the login user is returning the user name passed in and nothing for
>>>>> the range which would be used in the banner. During our installation
>>>>> we don't explicitly map this user to a SELinux user but our experience
>>>>> has been that the when there is no mapping the user and range of the
>>>>> '__default__' login are returned. Indeed once I rebuild policy this
>>>>> appears to be what is happening. How rebuilding and reloading policy
>>>>> would affect this is unclear.
>>>> If the installed seusers file (i.e. /etc/selinux/$SELINUXTYPE/seusers)
>>>> did not exist originally or was unreadable (e.g. wrong context or mode),
>>>> then getseuserbyname() would behave the way you described.  Rebuilding
>>>> policy would have caused the regenerated seusers file to be installed,
>>>> possibly with different context or mode than the original state.
>>>>
>>>> --
>>>> Stephen Smalley
>>>> National Security Agency
>>>>
>>>>
>>> You nailed it for some reason seusers is SystemHigh. Still
>>> investigating ... Thanks
>>>
>>> Ted
>>>
>> The plot thickens. semodule -B causes seusers to be relabeled
>> SystemLow. restorecon /etc/selinux/mls/seusers causes the file to be
>> relabeled SystemHigh. Which is right?
> 
> I don't think that semodule/libsemanage explicitly set the context of
> files they create, so they would just follow the default policy behavior
> (in this case, inheriting the level of the creating process and the type
> of the parent directory).
> 
> restorecon just applies whatever the file_contexts configuration
> specifies, which appears to be SystemHigh in the mls policy.  I'm not
> sure if that is truly justified.
> 
Since all the login programs have to read this file it should be at the
SystemLow, So that a login program running at a SystemLow can work.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmJvlcACgkQrlYvE4MpobN1hgCfdB4Tr/ZRIYfE1lwETN6y8Y+N
zuwAoLhuz3+aBxMZ8ZXVVnoL+r73tMG9
=mxpD
-----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: odd policy behavior

[Stephen Smalley]

On Wed, 2009-02-04 at 11:12 -0500, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stephen Smalley wrote:
> > On Tue, 2009-02-03 at 16:31 -0600, Xavier Toth wrote:
> >> On Tue, Feb 3, 2009 at 3:49 PM, Xavier Toth <txtoth@gmail.com> wrote:
> >>> On Tue, Feb 3, 2009 at 3:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >>>> On Tue, 2009-02-03 at 13:59 -0600, Xavier Toth wrote:
> >>>>> On Tue, Feb 3, 2009 at 10:38 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> >>>>>> On Tue, 2009-02-03 at 10:28 -0600, Xavier Toth wrote:
> >>>>>>> I have an app that wasn't working in enforcing but there are no AVCs.
> >>>>>>> So I did 'semodule -DB' to see if there were any dontaudit denials and
> >>>>>>> restarted the app. The problem is that the app then ran fine. So I
> >>>>>>> tried load_policy which had no affect and 'semodule -B' which makes it
> >>>>>>> work. Any ideas what could be happening? I've verified with 'semodule
> >>>>>>> --list' that the module is loaded prior to doing the 'semodule -B'.
> >>>>>> - How was the app failing?
> >>>>> This is our security banner app that draw a window across the top of
> >>>>> the screen with the users MLS range and with the appropriate
> >>>>> background color. When it fails there is just a window with a gray
> >>>>> background no text or color.
> >>>>>
> >>>>>> - Did you try running the app in permissive as well?
> >>>>>> - Is this reproducible at all or are you unable to reproduce the
> >>>>>> application failure now under any conditions?
> >>>>>> - Did the app create/use any transient resources (temporary files,
> >>>>>> system v ipc objects, etc) that could have prevented it from succeeding
> >>>>>> on subsequent execution if they weren't properly cleaned up on prior
> >>>>>> exit?
> >>>>> After further investigation I found that a call to getseuserbyname for
> >>>>> the login user is returning the user name passed in and nothing for
> >>>>> the range which would be used in the banner. During our installation
> >>>>> we don't explicitly map this user to a SELinux user but our experience
> >>>>> has been that the when there is no mapping the user and range of the
> >>>>> '__default__' login are returned. Indeed once I rebuild policy this
> >>>>> appears to be what is happening. How rebuilding and reloading policy
> >>>>> would affect this is unclear.
> >>>> If the installed seusers file (i.e. /etc/selinux/$SELINUXTYPE/seusers)
> >>>> did not exist originally or was unreadable (e.g. wrong context or mode),
> >>>> then getseuserbyname() would behave the way you described.  Rebuilding
> >>>> policy would have caused the regenerated seusers file to be installed,
> >>>> possibly with different context or mode than the original state.
> >>>>
> >>>> --
> >>>> Stephen Smalley
> >>>> National Security Agency
> >>>>
> >>>>
> >>> You nailed it for some reason seusers is SystemHigh. Still
> >>> investigating ... Thanks
> >>>
> >>> Ted
> >>>
> >> The plot thickens. semodule -B causes seusers to be relabeled
> >> SystemLow. restorecon /etc/selinux/mls/seusers causes the file to be
> >> relabeled SystemHigh. Which is right?
> > 
> > I don't think that semodule/libsemanage explicitly set the context of
> > files they create, so they would just follow the default policy behavior
> > (in this case, inheriting the level of the creating process and the type
> > of the parent directory).
> > 
> > restorecon just applies whatever the file_contexts configuration
> > specifies, which appears to be SystemHigh in the mls policy.  I'm not
> > sure if that is truly justified.
> > 
> Since all the login programs have to read this file it should be at the
> SystemLow, So that a login program running at a SystemLow can work.

Makes sense to me, but I assume that someone thought otherwise or it
wouldn't have been marked as SystemHigh in the first place?  Does the
LSPP impose a particular restriction on it?  There are
other /etc/selinux files in file_contexts as well that are marked with
SystemHigh (or to be precise, s15:c0.c1023) in the -mls policy.

-- 
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: odd policy behavior

[Daniel J Walsh]

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

Stephen Smalley wrote:
> On Wed, 2009-02-04 at 11:12 -0500, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Stephen Smalley wrote:
>>> On Tue, 2009-02-03 at 16:31 -0600, Xavier Toth wrote:
>>>> On Tue, Feb 3, 2009 at 3:49 PM, Xavier Toth <txtoth@gmail.com> wrote:
>>>>> On Tue, Feb 3, 2009 at 3:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>>>> On Tue, 2009-02-03 at 13:59 -0600, Xavier Toth wrote:
>>>>>>> On Tue, Feb 3, 2009 at 10:38 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>>>>>> On Tue, 2009-02-03 at 10:28 -0600, Xavier Toth wrote:
>>>>>>>>> I have an app that wasn't working in enforcing but there are no AVCs.
>>>>>>>>> So I did 'semodule -DB' to see if there were any dontaudit denials and
>>>>>>>>> restarted the app. The problem is that the app then ran fine. So I
>>>>>>>>> tried load_policy which had no affect and 'semodule -B' which makes it
>>>>>>>>> work. Any ideas what could be happening? I've verified with 'semodule
>>>>>>>>> --list' that the module is loaded prior to doing the 'semodule -B'.
>>>>>>>> - How was the app failing?
>>>>>>> This is our security banner app that draw a window across the top of
>>>>>>> the screen with the users MLS range and with the appropriate
>>>>>>> background color. When it fails there is just a window with a gray
>>>>>>> background no text or color.
>>>>>>>
>>>>>>>> - Did you try running the app in permissive as well?
>>>>>>>> - Is this reproducible at all or are you unable to reproduce the
>>>>>>>> application failure now under any conditions?
>>>>>>>> - Did the app create/use any transient resources (temporary files,
>>>>>>>> system v ipc objects, etc) that could have prevented it from succeeding
>>>>>>>> on subsequent execution if they weren't properly cleaned up on prior
>>>>>>>> exit?
>>>>>>> After further investigation I found that a call to getseuserbyname for
>>>>>>> the login user is returning the user name passed in and nothing for
>>>>>>> the range which would be used in the banner. During our installation
>>>>>>> we don't explicitly map this user to a SELinux user but our experience
>>>>>>> has been that the when there is no mapping the user and range of the
>>>>>>> '__default__' login are returned. Indeed once I rebuild policy this
>>>>>>> appears to be what is happening. How rebuilding and reloading policy
>>>>>>> would affect this is unclear.
>>>>>> If the installed seusers file (i.e. /etc/selinux/$SELINUXTYPE/seusers)
>>>>>> did not exist originally or was unreadable (e.g. wrong context or mode),
>>>>>> then getseuserbyname() would behave the way you described.  Rebuilding
>>>>>> policy would have caused the regenerated seusers file to be installed,
>>>>>> possibly with different context or mode than the original state.
>>>>>>
>>>>>> --
>>>>>> Stephen Smalley
>>>>>> National Security Agency
>>>>>>
>>>>>>
>>>>> You nailed it for some reason seusers is SystemHigh. Still
>>>>> investigating ... Thanks
>>>>>
>>>>> Ted
>>>>>
>>>> The plot thickens. semodule -B causes seusers to be relabeled
>>>> SystemLow. restorecon /etc/selinux/mls/seusers causes the file to be
>>>> relabeled SystemHigh. Which is right?
>>> I don't think that semodule/libsemanage explicitly set the context of
>>> files they create, so they would just follow the default policy behavior
>>> (in this case, inheriting the level of the creating process and the type
>>> of the parent directory).
>>>
>>> restorecon just applies whatever the file_contexts configuration
>>> specifies, which appears to be SystemHigh in the mls policy.  I'm not
>>> sure if that is truly justified.
>>>
>> Since all the login programs have to read this file it should be at the
>> SystemLow, So that a login program running at a SystemLow can work.
> 
> Makes sense to me, but I assume that someone thought otherwise or it
> wouldn't have been marked as SystemHigh in the first place?  Does the
> LSPP impose a particular restriction on it?  There are
> other /etc/selinux files in file_contexts as well that are marked with
> SystemHigh (or to be precise, s15:c0.c1023) in the -mls policy.
> 
I would think they were trying to protect these files from being
written, but the assumption is wrong, since if I can write to
/etc/passwd I can override controls also, and that is SystemLow.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmJwLAACgkQrlYvE4MpobPXzQCgq8lCmOfRSh5WtVH83v9Y8iwb
l/kAn3DCoC4armEq2NgcP+Vwto6kbYHl
=7U1X
-----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: odd policy behavior

[Joe Nall]

On Feb 4, 2009, at 10:14 AM, Stephen Smalley wrote:

> On Wed, 2009-02-04 at 11:12 -0500, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Stephen Smalley wrote:
>>> On Tue, 2009-02-03 at 16:31 -0600, Xavier Toth wrote:
>>>> On Tue, Feb 3, 2009 at 3:49 PM, Xavier Toth <txtoth@gmail.com>  
>>>> wrote:
>>>>> On Tue, Feb 3, 2009 at 3:28 PM, Stephen Smalley  
>>>>> <sds@tycho.nsa.gov> wrote:
>>>>>> On Tue, 2009-02-03 at 13:59 -0600, Xavier Toth wrote:
>>>>>>> On Tue, Feb 3, 2009 at 10:38 AM, Stephen Smalley <sds@tycho.nsa.gov 
>>>>>>> > wrote:
>>>>>>>> On Tue, 2009-02-03 at 10:28 -0600, Xavier Toth wrote:
>>>>>>>>> I have an app that wasn't working in enforcing but there are  
>>>>>>>>> no AVCs.
>>>>>>>>> So I did 'semodule -DB' to see if there were any dontaudit  
>>>>>>>>> denials and
>>>>>>>>> restarted the app. The problem is that the app then ran  
>>>>>>>>> fine. So I
>>>>>>>>> tried load_policy which had no affect and 'semodule -B'  
>>>>>>>>> which makes it
>>>>>>>>> work. Any ideas what could be happening? I've verified with  
>>>>>>>>> 'semodule
>>>>>>>>> --list' that the module is loaded prior to doing the  
>>>>>>>>> 'semodule -B'.
>>>>>>>> - How was the app failing?
>>>>>>> This is our security banner app that draw a window across the  
>>>>>>> top of
>>>>>>> the screen with the users MLS range and with the appropriate
>>>>>>> background color. When it fails there is just a window with a  
>>>>>>> gray
>>>>>>> background no text or color.
>>>>>>>
>>>>>>>> - Did you try running the app in permissive as well?
>>>>>>>> - Is this reproducible at all or are you unable to reproduce  
>>>>>>>> the
>>>>>>>> application failure now under any conditions?
>>>>>>>> - Did the app create/use any transient resources (temporary  
>>>>>>>> files,
>>>>>>>> system v ipc objects, etc) that could have prevented it from  
>>>>>>>> succeeding
>>>>>>>> on subsequent execution if they weren't properly cleaned up  
>>>>>>>> on prior
>>>>>>>> exit?
>>>>>>> After further investigation I found that a call to  
>>>>>>> getseuserbyname for
>>>>>>> the login user is returning the user name passed in and  
>>>>>>> nothing for
>>>>>>> the range which would be used in the banner. During our  
>>>>>>> installation
>>>>>>> we don't explicitly map this user to a SELinux user but our  
>>>>>>> experience
>>>>>>> has been that the when there is no mapping the user and range  
>>>>>>> of the
>>>>>>> '__default__' login are returned. Indeed once I rebuild policy  
>>>>>>> this
>>>>>>> appears to be what is happening. How rebuilding and reloading  
>>>>>>> policy
>>>>>>> would affect this is unclear.
>>>>>> If the installed seusers file (i.e. /etc/selinux/$SELINUXTYPE/ 
>>>>>> seusers)
>>>>>> did not exist originally or was unreadable (e.g. wrong context  
>>>>>> or mode),
>>>>>> then getseuserbyname() would behave the way you described.   
>>>>>> Rebuilding
>>>>>> policy would have caused the regenerated seusers file to be  
>>>>>> installed,
>>>>>> possibly with different context or mode than the original state.
>>>>>>
>>>>>> --
>>>>>> Stephen Smalley
>>>>>> National Security Agency
>>>>>>
>>>>>>
>>>>> You nailed it for some reason seusers is SystemHigh. Still
>>>>> investigating ... Thanks
>>>>>
>>>>> Ted
>>>>>
>>>> The plot thickens. semodule -B causes seusers to be relabeled
>>>> SystemLow. restorecon /etc/selinux/mls/seusers causes the file to  
>>>> be
>>>> relabeled SystemHigh. Which is right?
>>>
>>> I don't think that semodule/libsemanage explicitly set the context  
>>> of
>>> files they create, so they would just follow the default policy  
>>> behavior
>>> (in this case, inheriting the level of the creating process and  
>>> the type
>>> of the parent directory).
>>>
>>> restorecon just applies whatever the file_contexts configuration
>>> specifies, which appears to be SystemHigh in the mls policy.  I'm  
>>> not
>>> sure if that is truly justified.
>>>
>> Since all the login programs have to read this file it should be at  
>> the
>> SystemLow, So that a login program running at a SystemLow can work.
>
> Makes sense to me, but I assume that someone thought otherwise or it
> wouldn't have been marked as SystemHigh in the first place?  Does the
> LSPP impose a particular restriction on it?  There are
> other /etc/selinux files in file_contexts as well that are marked with
> SystemHigh (or to be precise, s15:c0.c1023) in the -mls policy.


Here is the original rationale:

> From: Darrel Goeddel ...
> The theory is that these files can contain the lables up to  
> systemhigh.  The
> mere existence of the label is classified just like data having that  
> label.
> Since the seusers file contains the clearances, those labels need to  
> be
> protected with the appropriate labels (ain't that fun...).  This is  
> same
> reason that the label translation daemon will not translate things for
> you if you are not cleared to know about the translation.  We are  
> trying
> to prevent someone who is cleared at secret (let's say s7) to be able
> to read the seusers file and find out that the label (s10:c0-c100)  
> is in
> use on the system, possibly indicating that the machine is a higher- 
> value
> target.

I think this over classifies the file. Since the contexts are raw, I  
don't see a reason for seusers to be SystemHigh. I'll ask our  
accreditors, but the answer will not be swiftly forthcoming.

WRT the other files, setrans.conf should be SystemHigh because there  
is sensitivity to category names in some communities.

joe



--
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: odd policy behavior

[James W. Hoeft]

Joe Nall wrote:
>
> On Feb 4, 2009, at 10:14 AM, Stephen Smalley wrote:
>
>> On Wed, 2009-02-04 at 11:12 -0500, Daniel J Walsh wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Stephen Smalley wrote:
>>>> On Tue, 2009-02-03 at 16:31 -0600, Xavier Toth wrote:
>>>>> On Tue, Feb 3, 2009 at 3:49 PM, Xavier Toth <txtoth@gmail.com> wrote:
>>>>>> On Tue, Feb 3, 2009 at 3:28 PM, Stephen Smalley 
>>>>>> <sds@tycho.nsa.gov> wrote:
>>>>>>> On Tue, 2009-02-03 at 13:59 -0600, Xavier Toth wrote:
>>>>>>>> On Tue, Feb 3, 2009 at 10:38 AM, Stephen Smalley 
>>>>>>>> <sds@tycho.nsa.gov> wrote:
>>>>>>>>> On Tue, 2009-02-03 at 10:28 -0600, Xavier Toth wrote:
>>>>>>>>>> I have an app that wasn't working in enforcing but there are 
>>>>>>>>>> no AVCs.
>>>>>>>>>> So I did 'semodule -DB' to see if there were any dontaudit 
>>>>>>>>>> denials and
>>>>>>>>>> restarted the app. The problem is that the app then ran fine. 
>>>>>>>>>> So I
>>>>>>>>>> tried load_policy which had no affect and 'semodule -B' which 
>>>>>>>>>> makes it
>>>>>>>>>> work. Any ideas what could be happening? I've verified with 
>>>>>>>>>> 'semodule
>>>>>>>>>> --list' that the module is loaded prior to doing the 
>>>>>>>>>> 'semodule -B'.
>>>>>>>>> - How was the app failing?
>>>>>>>> This is our security banner app that draw a window across the 
>>>>>>>> top of
>>>>>>>> the screen with the users MLS range and with the appropriate
>>>>>>>> background color. When it fails there is just a window with a gray
>>>>>>>> background no text or color.
>>>>>>>>
>>>>>>>>> - Did you try running the app in permissive as well?
>>>>>>>>> - Is this reproducible at all or are you unable to reproduce the
>>>>>>>>> application failure now under any conditions?
>>>>>>>>> - Did the app create/use any transient resources (temporary 
>>>>>>>>> files,
>>>>>>>>> system v ipc objects, etc) that could have prevented it from 
>>>>>>>>> succeeding
>>>>>>>>> on subsequent execution if they weren't properly cleaned up on 
>>>>>>>>> prior
>>>>>>>>> exit?
>>>>>>>> After further investigation I found that a call to 
>>>>>>>> getseuserbyname for
>>>>>>>> the login user is returning the user name passed in and nothing 
>>>>>>>> for
>>>>>>>> the range which would be used in the banner. During our 
>>>>>>>> installation
>>>>>>>> we don't explicitly map this user to a SELinux user but our 
>>>>>>>> experience
>>>>>>>> has been that the when there is no mapping the user and range 
>>>>>>>> of the
>>>>>>>> '__default__' login are returned. Indeed once I rebuild policy 
>>>>>>>> this
>>>>>>>> appears to be what is happening. How rebuilding and reloading 
>>>>>>>> policy
>>>>>>>> would affect this is unclear.
>>>>>>> If the installed seusers file (i.e. 
>>>>>>> /etc/selinux/$SELINUXTYPE/seusers)
>>>>>>> did not exist originally or was unreadable (e.g. wrong context 
>>>>>>> or mode),
>>>>>>> then getseuserbyname() would behave the way you described.  
>>>>>>> Rebuilding
>>>>>>> policy would have caused the regenerated seusers file to be 
>>>>>>> installed,
>>>>>>> possibly with different context or mode than the original state.
>>>>>>>
>>>>>>> -- 
>>>>>>> Stephen Smalley
>>>>>>> National Security Agency
>>>>>>>
>>>>>>>
>>>>>> You nailed it for some reason seusers is SystemHigh. Still
>>>>>> investigating ... Thanks
>>>>>>
>>>>>> Ted
>>>>>>
>>>>> The plot thickens. semodule -B causes seusers to be relabeled
>>>>> SystemLow. restorecon /etc/selinux/mls/seusers causes the file to be
>>>>> relabeled SystemHigh. Which is right?
>>>>
>>>> I don't think that semodule/libsemanage explicitly set the context of
>>>> files they create, so they would just follow the default policy 
>>>> behavior
>>>> (in this case, inheriting the level of the creating process and the 
>>>> type
>>>> of the parent directory).
>>>>
>>>> restorecon just applies whatever the file_contexts configuration
>>>> specifies, which appears to be SystemHigh in the mls policy.  I'm not
>>>> sure if that is truly justified.
>>>>
>>> Since all the login programs have to read this file it should be at the
>>> SystemLow, So that a login program running at a SystemLow can work.
>>
>> Makes sense to me, but I assume that someone thought otherwise or it
>> wouldn't have been marked as SystemHigh in the first place?  Does the
>> LSPP impose a particular restriction on it?  There are
>> other /etc/selinux files in file_contexts as well that are marked with
>> SystemHigh (or to be precise, s15:c0.c1023) in the -mls policy.
>
>
> Here is the original rationale:
>
>> From: Darrel Goeddel ...
>> The theory is that these files can contain the lables up to 
>> systemhigh.  The
>> mere existence of the label is classified just like data having that 
>> label.
>> Since the seusers file contains the clearances, those labels need to be
>> protected with the appropriate labels (ain't that fun...).  This is same
>> reason that the label translation daemon will not translate things for
>> you if you are not cleared to know about the translation.  We are trying
>> to prevent someone who is cleared at secret (let's say s7) to be able
>> to read the seusers file and find out that the label (s10:c0-c100) is in
>> use on the system, possibly indicating that the machine is a 
>> higher-value
>> target.
>
> I think this over classifies the file. Since the contexts are raw, I 
> don't see a reason for seusers to be SystemHigh. I'll ask our 
> accreditors, but the answer will not be swiftly forthcoming.
>
> WRT the other files, setrans.conf should be SystemHigh because there 
> is sensitivity to category names in some communities.
>
> joe
>
Short answer (with concurrence from our certifier rep - program Joe and 
Ted are working) is the file should not be classified. Raw contexts 
themselves do not mean much - translating them into actual clearances is 
the part that needs to be protected (i.e., an unauthorized user/process 
determining there is s8:c134 data on a system does not mean much; 
however, for them to be able to determine there is 
"confidential:specialcodeword" data could be an issue).

Jim

--
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: odd policy behavior

[chanson]

 
> > >> The plot thickens. semodule -B causes seusers to be relabeled
> > >> SystemLow. restorecon /etc/selinux/mls/seusers causes the file to
be
> > >> relabeled SystemHigh. Which is right?
> > > 
> > > I don't think that semodule/libsemanage explicitly set the context
of
> > > files they create, so they would just follow the default policy
behavior
> > > (in this case, inheriting the level of the creating process and
the type
> > > of the parent directory).
> > > 
> > > restorecon just applies whatever the file_contexts configuration
> > > specifies, which appears to be SystemHigh in the mls policy.  I'm
not
> > > sure if that is truly justified.
> > > 
> > Since all the login programs have to read this file it should be at
the
> > SystemLow, So that a login program running at a SystemLow can work.
> 
> Makes sense to me, but I assume that someone thought otherwise or it
> wouldn't have been marked as SystemHigh in the first place?  Does the
> LSPP impose a particular restriction on it?  There are
> other /etc/selinux files in file_contexts as well that are marked with
> SystemHigh (or to be precise, s15:c0.c1023) in the -mls policy.

I agree that the SystemHigh labeling of this file is probably overkill,
but we may have erred on the conservative side. I can see how this gets
in the way of getseuserbyname(). The RHEL 5.1 LSPP Configuration Guide
is a bit murky in this area. Section 4.3 states the administrator should
pick SystemLow or SystemHigh for administrative actions as well a note
for SystemLow for system administration. As noted above, the seusers
will get created at SystemLow or SystemHigh depending on the process
label when executing 'semodule -B'. The restorecon settings of the
policy can cause a a couple of problems. We perform policy management at
SystemHigh and have different inconsistencies, than seusers, with
restorecon based on running at SystemHigh. The other issue with the
restorecon is that the SELinux User will for the policy files will
always be different than the 'system_u' defined for the file after
running 'semodule -B' as 'staff_u' for example. This can be a problem if
you are storing SELinux attributes for integrity purposes or checking
them with restorecon.

-Chad


--
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: odd policy behavior

[Daniel J Walsh]

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

Daniel J Walsh wrote:
> Stephen Smalley wrote:
>> On Tue, 2009-02-03 at 16:31 -0600, Xavier Toth wrote:
>>> On Tue, Feb 3, 2009 at 3:49 PM, Xavier Toth <txtoth@gmail.com> wrote:
>>>> On Tue, Feb 3, 2009 at 3:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>>> On Tue, 2009-02-03 at 13:59 -0600, Xavier Toth wrote:
>>>>>> On Tue, Feb 3, 2009 at 10:38 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>>>>> On Tue, 2009-02-03 at 10:28 -0600, Xavier Toth wrote:
>>>>>>>> I have an app that wasn't working in enforcing but there are no AVCs.
>>>>>>>> So I did 'semodule -DB' to see if there were any dontaudit denials and
>>>>>>>> restarted the app. The problem is that the app then ran fine. So I
>>>>>>>> tried load_policy which had no affect and 'semodule -B' which makes it
>>>>>>>> work. Any ideas what could be happening? I've verified with 'semodule
>>>>>>>> --list' that the module is loaded prior to doing the 'semodule -B'.
>>>>>>> - How was the app failing?
>>>>>> This is our security banner app that draw a window across the top of
>>>>>> the screen with the users MLS range and with the appropriate
>>>>>> background color. When it fails there is just a window with a gray
>>>>>> background no text or color.
>>>>>>
>>>>>>> - Did you try running the app in permissive as well?
>>>>>>> - Is this reproducible at all or are you unable to reproduce the
>>>>>>> application failure now under any conditions?
>>>>>>> - Did the app create/use any transient resources (temporary files,
>>>>>>> system v ipc objects, etc) that could have prevented it from succeeding
>>>>>>> on subsequent execution if they weren't properly cleaned up on prior
>>>>>>> exit?
>>>>>> After further investigation I found that a call to getseuserbyname for
>>>>>> the login user is returning the user name passed in and nothing for
>>>>>> the range which would be used in the banner. During our installation
>>>>>> we don't explicitly map this user to a SELinux user but our experience
>>>>>> has been that the when there is no mapping the user and range of the
>>>>>> '__default__' login are returned. Indeed once I rebuild policy this
>>>>>> appears to be what is happening. How rebuilding and reloading policy
>>>>>> would affect this is unclear.
>>>>> If the installed seusers file (i.e. /etc/selinux/$SELINUXTYPE/seusers)
>>>>> did not exist originally or was unreadable (e.g. wrong context or mode),
>>>>> then getseuserbyname() would behave the way you described.  Rebuilding
>>>>> policy would have caused the regenerated seusers file to be installed,
>>>>> possibly with different context or mode than the original state.
>>>>>
>>>>> --
>>>>> Stephen Smalley
>>>>> National Security Agency
>>>>>
>>>>>
>>>> You nailed it for some reason seusers is SystemHigh. Still
>>>> investigating ... Thanks
>>>>
>>>> Ted
>>>>
>>> The plot thickens. semodule -B causes seusers to be relabeled
>>> SystemLow. restorecon /etc/selinux/mls/seusers causes the file to be
>>> relabeled SystemHigh. Which is right?
>> I don't think that semodule/libsemanage explicitly set the context of
>> files they create, so they would just follow the default policy behavior
>> (in this case, inheriting the level of the creating process and the type
>> of the parent directory).
> 
>> restorecon just applies whatever the file_contexts configuration
>> specifies, which appears to be SystemHigh in the mls policy.  I'm not
>> sure if that is truly justified.
> 
> Since all the login programs have to read this file it should be at the
> SystemLow, So that a login program running at a SystemLow can work.

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


If we conclude that this file(s) should be SystemHigh, then we need to
change semanage to use setfscreatecon, when creating these files.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkmJwR0ACgkQrlYvE4MpobMKnQCeJbQO7RwtWlL6eFDByKnYWoh2
S0AAnA1cChgHe31C5j+9iD/2x9RQw2L+
=+pzu
-----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.