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