SELinux Reset

[Stephen Smalley]

On Mon, 2009-08-10 at 07:21 -0700, Justin P. Mattock wrote:
> Daniel J Walsh wrote:
> > On 08/10/2009 09:06 AM, max bianco wrote:
> >    
> >> On Mon, Aug 10, 2009 at 7:45 AM, Stephen Smalley<sds at tycho.nsa.gov>  wrote:
> >>      
> >>> On Sat, 2009-08-08 at 00:45 -0700, Justin P. Mattock wrote:
> >>>        
> >>>> Peter Joseph wrote:
> >>>>          
> >>>>>> enforcing =0 should work.
> >>>>>> are you putting it the right area in grub/lilo?
> >>>>>> also you should be able to just change
> >>>>>> /etc/selinux/config
> >>>>>> set to permissive mode to avoid using the boot command line.
> >>>>>> or
> >>>>>> setenforce 0
> >>>>>> and
> >>>>>> echo 0>   /selinux/enforce
> >>>>>> to put the policy in permissive mode until things get cleaned.
> >>>>>> Justin P. Mattock
> >>>>>>
> >>>>>>              
> >>>>> --
> >>>>> SELinux has to be completely DISABLED for anybody to log in.  Changing
> >>>>> /etc/selinux/config to a permissive mode is of no use.
> >>>>> I am thinking about trying to change all booleans from deny to allow (wow,
> >>>>> what a monstrous task).  After all, that is how this trouble started in the
> >>>>> first place.
> >>>>> PJ
> >>>>>
> >>>>> fedora-selinux-list mailing list
> >>>>> fedora-selinux-list at redhat.com
> >>>>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>            
> >>>> yeah but booleans don't mess with the
> >>>> MBR or the bootloader of the kernel?
> >>>>          
> >>> No, they are part of the policy image (if set persistently).
> >>>
> >>> But the booleans only affect what allow rules are enabled at any given
> >>> time.  If the system is in permissive mode, then the boolean settings
> >>> shouldn't prevent anything from working; they will just affect what avc
> >>> denials get logged.
> >>>
> >>> enforcing=0 on the kernel command line or SELINUX=permissive
> >>> in /etc/selinux/config should resolve any SELinux-related denials.
> >>>
> >>> Out of curiosity, you didn't happen to change the xserver_object_manager
> >>> boolean, did you?
> >>>
> >>>        
> >> It was the unconfined_login boolean that got him.
> >>
> >>
> >>
> >>      
> > So disabling unconfined_login boolean stopped him from being able to login?
> >
> > --
> > fedora-selinux-list mailing list
> > fedora-selinux-list at redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >
> >    
> Still confused on how he was not able to use lilo/grub
> command option.(unless he was putting enforcing/selinux
> on the wrong line.
> 
> As for the unconfined_login I can see how they got stuck
> (probably needed to make enableaudit to see the extra denials).

It would have changed not only permission checks but also the list of
reachable contexts returned by libselinux when asked by pam_selinux.
Which could have led to no legal contexts being available for the user
and thus unable to login.

-- 
Stephen Smalley
National Security Agency