-----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@xxxxxxxxx> wrote: >>> On Tue, Feb 3, 2009 at 3:28 PM, Stephen Smalley <sds@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
