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