-----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@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. > > 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@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
