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