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