Re: odd policy behavior

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


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

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux