SELinux Reset

[Peter Joseph]

While experimenting with SELinux, I finally managed to lock myself out of the
system.  The only way to get back in, I had to add "selinux=0" to the end of
the kernel line.
Now, if I run in a permissive mode the following message appears when I try
to log in:

"Could not connect to session bus: An SELinux policy prevents this sender
from sending this message to this recipient (rejected message had sender
"(unset)" interface "org.freedesktop.DBus" member "Hello"
error name
"(unset)" destination "org.freedesktop.DBus)."

I am forced to go back to the grub prompt and disable SELinux again, in
order to get in.  What is the best way to reset SEL to its original state?
-- 
View this message in context:
http://www.nabble.com/SELinux-Reset-tp24855587p24855587.html
Sent from the Fedora SELinux List mailing list archive at Nabble.com.

[Justin P. Mattock]

Peter Joseph wrote:
>  While experimenting with SELinux, I finally managed to lock myself
> out of the
>  system.  The only way to get back in, I had to add "selinux=0" to the end of
>  the kernel line.
>  Now, if I run in a permissive mode the following message appears when I try
>  to log in:
>
>  "Could not connect to session bus: An SELinux policy prevents this sender
>  from sending this message to this recipient (rejected message had sender
>  "(unset)" interface "org.freedesktop.DBus" member "Hello"
> error name
>  "(unset)" destination "org.freedesktop.DBus)."
>
>  I am forced to go back to the grub prompt and disable SELinux again, in
>  order to get in.  What is the best way to reset SEL to its original state?
>      
try updating dbus
(message is something in /etc/dbus-1/*)

for the policy use enforcing=0 for permissive
selinux=0 to disable completely

Justin P. Mattock

[Daniel J Walsh]

On 08/06/2009 06:21 PM, Peter Joseph wrote:
>  While experimenting with SELinux, I finally managed to lock myself
> out of the
>  system.  The only way to get back in, I had to add "selinux=0" to the end of
>  the kernel line.
>  Now, if I run in a permissive mode the following message appears when I try
>  to log in:
>  
>  "Could not connect to session bus: An SELinux policy prevents this sender
>  from sending this message to this recipient (rejected message had sender
>  "(unset)" interface "org.freedesktop.DBus" member "Hello"
> error name
>  "(unset)" destination "org.freedesktop.DBus)."
>  
>  I am forced to go back to the grub prompt and disable SELinux again, in
>  order to get in.  What is the best way to reset SEL to its original state? 
I have
no idea what is going on on your system.  I would figure you either have a problem with
labeling, or you 
have a problem upgrading from an older version of SELInux.

Did you upgrade or was this a fresh install?
If an Upgrade, what version to what version

Also what does

# semanage login -l 
show?
# semodule -l | grep unconfined
Show?

[Peter Joseph]

This is a fresh install , Kernel Linux 2.6.29.4-167.fc11.i586
___________________________________________________
# semanage login -l

Login Name                SELinux User              MLS/MCS Range            

__default__               unconfined_u              s0-s0:c0.c1023           
root                      unconfined_u              s0-s0:c0.c1023           
system_u                  system_u                  s0-s0:c0.c1023 
___________________________________________________
# module -l | grep unconfined

unconfined	3.0.1
unconfineduser	1.0.0
___________________________________________________
Using enforcing=0 results in inability to log in.  "Could not acquire name
on session bus"
Looked into  /etc/dbus-1/*, did not recognized anything as being out of
ordinary that would need updating (what do I know?).

I am thinking about re-installation and then try to duplicate the error. 
There should be a way of fixing this.


Daniel J Walsh wrote:
>  
>  On 08/06/2009 06:21 PM, Peter Joseph wrote:
> > While experimenting with SELinux, I finally managed to lock myself out of
> > the.....
>  
>  I have no idea what is going on on your system.  I would figure you either
>  have a problem with labeling, or you 
>  have a problem upgrading from an older version of SELInux.
>  
>  Did you upgrade or was this a fresh install?
>  If an Upgrade, what version to what version
>  
>  Also what does
>  
>  # semanage login -l 
>  show?
>  # semodule -l | grep unconfined
>  Show?
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  
>   
-- 
View this message in context:
http://www.nabble.com/SELinux-Reset-tp24855587p24872725.html
Sent from the Fedora SELinux List mailing list archive at Nabble.com.

[Justin P. Mattock]

Peter Joseph wrote:
>  This is a fresh install , Kernel Linux 2.6.29.4-167.fc11.i586
>  ___________________________________________________
>  # semanage login -l
>
>  Login Name                SELinux User              MLS/MCS Range
>
>  __default__               unconfined_u              s0-s0:c0.c1023
>  root                      unconfined_u              s0-s0:c0.c1023
>  system_u                  system_u                  s0-s0:c0.c1023
>  ___________________________________________________
>  # module -l | grep unconfined
>
>  unconfined	3.0.1
>  unconfineduser	1.0.0
>  ___________________________________________________
>  Using enforcing=0 results in inability to log in.  "Could not acquire name
>  on session bus"
>  Looked into  /etc/dbus-1/*, did not recognized anything as being out of
>  ordinary that would need updating (what do I know?).
>
>  I am thinking about re-installation and then try to duplicate the error.
>  There should be a way of fixing this.
>
>
>  Daniel J Walsh wrote:
>     
> > On 08/06/2009 06:21 PM, Peter Joseph wrote:
> >      
> >> While experimenting with SELinux, I finally managed to lock myself out of
> >> the.....
> >>        
> > I have no idea what is going on on your system.  I would figure you either
> > have a problem with labeling, or you
> > have a problem upgrading from an older version of SELInux.
> >
> > Did you upgrade or was this a fresh install?
> > If an Upgrade, what version to what version
> >
> > Also what does
> >
> > # semanage login -l
> > show?
> > # semodule -l | grep unconfined
> > Show?
> >
> > --
> > fedora-selinux-list mailing list
> > fedora-selinux-list(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-selinux-list
> >
> >
> >      
>
>      
Hmm, this should not happen on a fresh
fedora 11 install.
  from just looking, it sounds
like the dbus user is not correct. i.g. on my system
I have built dbus to have a user name.
if  I look in /etc/group
it says
messagebus:x:111:myname
distros I think do this differently.

Justin P. Mattock

[Peter Joseph]

Hmm, this should not happen on a fresh
fedora 11 install.
  from just looking, it sounds
like the dbus user is not correct. i.g. on my system
I have built dbus to have a user name.
if  I look in /etc/group
it says
messagebus:x:111:myname
distros I think do this differently.

Justin P. Mattock
--

Yes, I looked into /etc/group - dbus user is set as follows:
dbus:x:81: 

fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list



-- 
View this message in context:
http://www.nabble.com/SELinux-Reset-tp24855587p24873486.html
Sent from the Fedora SELinux List mailing list archive at Nabble.com.

[Justin P. Mattock]

Peter Joseph wrote:
>  Hmm, this should not happen on a fresh
>  fedora 11 install.
>     from just looking, it sounds
>  like the dbus user is not correct. i.g. on my system
>  I have built dbus to have a user name.
>  if  I look in /etc/group
>  it says
>  messagebus:x:111:myname
>  distros I think do this differently.
>
>  Justin P. Mattock
>  --
>
>  Yes, I looked into /etc/group - dbus user is set as follows:
>  dbus:x:81:
>
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
>
>
>      
hmm.
that looks right.
what you might try, is loading a fresh
dbus install from source(if you feel comfortable
with that) and during the ./configure stage
add the dbus-user switch then after installing
add your name to /etc/group(or before installing)

dbus:x:81:yourname

this way you know that dbus is compiled
with you as the username, and that any other issue
might be in /etc/dbus-1/*
in some config file.(or check /etc/dbus-1/*
first before compiling)

heres a good set of instructions:
http://www.linuxfromscratch.org/lfs/view/development/

Justin P. Mattock

[max]

On Fri, Aug 7, 2009 at 6:08 PM, Peter Joseph<peterjb(a)mtaonline.net> wrote:
>  This is a fresh install , Kernel Linux 2.6.29.4-167.fc11.i586
>  ___________________________________________________
>  # semanage login -l
>
>  Login Name                SELinux User              MLS/MCS Range
>
>  __default__               unconfined_u              s0-s0:c0.c1023
>  root                      unconfined_u              s0-s0:c0.c1023
>  system_u                  system_u                  s0-s0:c0.c1023
>  ___________________________________________________
>  # module -l | grep unconfined
>
>  unconfined      3.0.1
>  unconfineduser  1.0.0
>  ___________________________________________________
>  Using enforcing=0 results in inability to log in.  "Could not acquire name
>  on session bus"
>  Looked into  /etc/dbus-1/*, did not recognized anything as being out of
>  ordinary that would need updating (what do I know?).
>
>  I am thinking about re-installation and then try to duplicate the error.
>  There should be a way of fixing this.
>  
You mentioned that you were experimenting but you didn't elaborate ,
were you trying to install refpolicy or something?

[Peter Joseph]

> You mentioned that you were experimenting but you didn't elaborate
> ,
> were you trying to install refpolicy or something? 
--
I was studying the effects of Boolean settings on the system (yes I am new
to all this) and during my last trial I got distracted and did not record
the changes.  As I said before, I am going to trash the system and start
allover again.  I don't want to waste anyone's time trying to resolve this. 
If  I pinpoint the cause I will post the results.  Everyone's help is
greatly appreciated.
ps
The "enforcing=0 autorelabel" does not work either.
 
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list



-- 
View this message in context:
http://www.nabble.com/SELinux-Reset-tp24855587p24875131.html
Sent from the Fedora SELinux List mailing list archive at Nabble.com.

[Justin P. Mattock]

Peter Joseph wrote:
> > You mentioned that you were experimenting but you didn't
> elaborate ,
> > were you trying to install refpolicy or something?
> >      
>
>  --
>  I was studying the effects of Boolean settings on the system (yes I am new
>  to all this) and during my last trial I got distracted and did not record
>  the changes.  As I said before, I am going to trash the system and start
>  allover again.  I don't want to waste anyone's time trying to resolve this.
>  If  I pinpoint the cause I will post the results.  Everyone's help is
>  greatly appreciated.
>  ps
>  The "enforcing=0 autorelabel" does not work either.
>
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
>
>
>      
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

[Peter Joseph]

> 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(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list



-- 
View this message in context:
http://www.nabble.com/SELinux-Reset-tp24855587p24875604.html
Sent from the Fedora SELinux List mailing list archive at Nabble.com.

[Justin P. Mattock]

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(a)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?

Justin P. Mattock

[Stephen Smalley]

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(a)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?

-- 
Stephen Smalley
National Security Agency

[max]

On Mon, Aug 10, 2009 at 7:45 AM, Stephen Smalley<sds(a)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(a)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.



-- 
The convoluted wording of legalisms grew up around the necessity to
hide from ourselves the violence we intend toward each other. Between
depriving a man of one hour from his life and depriving him of his
life there exists only a difference of degree. You have done violence
to him, consumed his energy. Elaborate euphemisms may conceal your
intent to kill, but behind any use of power over another the ultimate
assumption remains: "I feed on your energy."

-Addenda to Orders in Council
 The Emperor Paul Muad'dib

[Daniel J Walsh]

On 08/10/2009 09:06 AM, max bianco wrote:
>  On Mon, Aug 10, 2009 at 7:45 AM, Stephen
> Smalley<sds(a)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(a)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?

[max]

On Mon, Aug 10, 2009 at 9:55 AM, Daniel J Walsh<dwalsh(a)redhat.com> wrote:
>  On 08/10/2009 09:06 AM, max bianco wrote:
> > On Mon, Aug 10, 2009 at 7:45 AM, Stephen Smalley<sds(a)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(a)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?
>  
That's what he told me. I told him to check xserver_allow_execmem and
unconfined_login.
It would have hit the list but I did the reply instead of reply all.
Anyway he said the unconfined_login fixed his problem.

here it is:

On Sun, Aug 9, 2009 at 4:51 PM, <peterjb(a)mail.com&gt; wrote:
> >check the xserver_allow_execmem and unconfined_login booleans.
>
>  You got it!  The problem stems from unconfined_login --> off.
>
>  Thanks for your help.
>
>  pj
>

[Peter Joseph]

> >> It was the unconfined_login boolean that got him
> >
> > So disabling unconfined_login boolean stopped him from being able to
> > login? 
That is correct.

[root@rf57 active]# cat booleans.local
# This file is auto-generated by libsemanage
# Do not edit directly.

allow_xserver_execmem=1
unconfined_login=0 
__________________________________

Not being able to solve the problem I re-installed F11 and change the
default setting of unconfined_login again.  Sure enough,  the only way to
get back in is by setting selinux=0.

I tried all sorts of ways to restore it to its default, but the problem I am
running into is:

root@rf57 r5f7]# /usr/sbin/getenforce
Disabled

[root@rf57 r5f7]# /usr/sbin/getsebool unconfined_login
/usr/sbin/getsebool:  SELinux is disabled

[root@rf57 selinux]# setsebool unconfined_login 1
setsebool:  SELinux is disabled.

There has to be a way of getting around this.

--
fedora-selinux-list mailing list
fedora-selinux-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-selinux-list



-- 
View this message in context:
http://www.nabble.com/SELinux-Reset-tp24855587p24903910.html
Sent from the Fedora SELinux List mailing list archive at Nabble.com.

[Stephen Smalley]

On Mon, 2009-08-10 at 10:26 -0700, Peter Joseph wrote:
>  >>> It was the unconfined_login boolean that got him
>  >>
>  >> So disabling unconfined_login boolean stopped him from being able to
>  >> login?
>  
>  That is correct.
>  
>  [root@rf57 active]# cat booleans.local
>  # This file is auto-generated by libsemanage
>  # Do not edit directly.
>  
>  allow_xserver_execmem=1
>  unconfined_login=0 
>  __________________________________
>  
>  Not being able to solve the problem I re-installed F11 and change the
>  default setting of unconfined_login again.  Sure enough,  the only way to
>  get back in is by setting selinux=0.
>  
>  I tried all sorts of ways to restore it to its default, but the problem I am
>  running into is:
>  
>  root@rf57 r5f7]# /usr/sbin/getenforce
>  Disabled
>  
>  [root@rf57 r5f7]# /usr/sbin/getsebool unconfined_login
>  /usr/sbin/getsebool:  SELinux is disabled
>  
>  [root@rf57 selinux]# setsebool unconfined_login 1
>  setsebool:  SELinux is disabled.
>  
>  There has to be a way of getting around this. 
Hmm..setsebool probably shouldn't require SELinux to be enabled (but
you'd want the -P option anyway to set it persistently).  What about
semanage or system-config-selinux, e.g.:

semanage boolean -m --on unconfined_login

Or you could edit the file directly (despite the comments) and run
semodule -B afterward.

-- 
Stephen Smalley
National Security Agency

[Justin P. Mattock]

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(a)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(a)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(a)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).

Justin P. Mattock

[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(a)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(a)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(a)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

[Stephen Smalley]

On Thu, 2009-08-06 at 15:21 -0700, Peter Joseph wrote:
>  While experimenting with SELinux, I finally managed to lock myself
> out of the
>  system.  The only way to get back in, I had to add "selinux=0" to the end of
>  the kernel line.
>  Now, if I run in a permissive mode the following message appears when I try
>  to log in:
>  
>  "Could not connect to session bus: An SELinux policy prevents this sender
>  from sending this message to this recipient (rejected message had sender
>  "(unset)" interface "org.freedesktop.DBus" member "Hello"
> error name
>  "(unset)" destination "org.freedesktop.DBus)."
>  
>  I am forced to go back to the grub prompt and disable SELinux again, in
>  order to get in.  What is the best way to reset SEL to its original state? 
Boot with enforcing=0 to come up in permissive mode (i.e. stay enabled,
log any denials that would occur, but don't enforce them).

Then look for avc denial messages in /var/log/messages
or /var/log/audit/audit.log.  Those will help indicate what it is going
wrong and what needs to be fixed.

-- 
Stephen Smalley
National Security Agency

[Peter Joseph]

Peter Joseph wrote:
>  
> >While experimenting with SELinux, I finally managed to lock myself out of 
the
system.  The only way to get back in, I had >to add "selinux=0" to the
end of the kernel line.
> >Now, if I run in a permissive mode the following message appears
> when I 
try to log in:
>  
> >"Could not connect to session bus: An SELinux policy prevents this sender
from sending this message to this recipient >(rejected message had sender
"(unset)" interface "org.freedesktop.DBus" member "Hello"
error name
"(unset)" destination >"org.freedesktop.DBus)."
>  
> >I am forced to go back to the grub prompt and disable SELinux again, in 
order to
get in.  What is the best way to reset >SEL to its original state?
>   
Problem solved.

Appending selinux=0 to the end of the kernel line enabled me to get back
into the system, however, I found no way of working with SELinux on account
of it being disabled.
Appending unconfined_login = 1 instead, brought me to a root prompt with
SELinux enabled.
Used the following to check and restore:

# getsebool unconfined_login
  unconfined_login --> off

# setsebool -P unconfined_login=1

# getsebool unconfined_login
  unconfined_login --> on

# poweroff

One thing though, the "unconfined_login = 1" added to the kernel line has to
contain a space before and after the equal sign. 


-- 
View this message in context:
http://www.nabble.com/SELinux-Reset-tp24855587p24905702.html
Sent from the Fedora SELinux List mailing list archive at Nabble.com.

[Stephen Smalley]

On Mon, 2009-08-10 at 12:10 -0700, Peter Joseph wrote:
>  
>  Peter Joseph wrote:
>  > 
>  >>While experimenting with SELinux, I finally managed to lock myself out of
>  the system.  The only way to get back in, I had >to add "selinux=0" to the
>  end of the kernel line.
>  >>Now, if I run in a permissive mode the following message appears when I
>  try to log in:
>  > 
>  >>"Could not connect to session bus: An SELinux policy prevents this sender
>  from sending this message to this recipient >(rejected message had sender
>  "(unset)" interface "org.freedesktop.DBus" member "Hello"
> error name
>  "(unset)" destination >"org.freedesktop.DBus)."
>  > 
>  >>I am forced to go back to the grub prompt and disable SELinux again, in
>  order to get in.  What is the best way to reset >SEL to its original state?
>  > 
>  
>  Problem solved.
>  
>  Appending selinux=0 to the end of the kernel line enabled me to get back
>  into the system, however, I found no way of working with SELinux on account
>  of it being disabled.
>  Appending unconfined_login = 1 instead, brought me to a root prompt with
>  SELinux enabled.
>  Used the following to check and restore:
>  
>  # getsebool unconfined_login
>    unconfined_login --> off
>  
>  # setsebool -P unconfined_login=1
>  
>  # getsebool unconfined_login
>    unconfined_login --> on
>  
>  # poweroff
>  
>  One thing though, the "unconfined_login = 1" added to the kernel line has to
>  contain a space before and after the equal sign.  
I think that just caused it to boot to runlevel 1, i.e. single-user
mode.  AFAIK, the kernel command line isn't used for booleans at all,
but an integer argument will be taken as the runlevel by init.

-- 
Stephen Smalley
National Security Agency

[Peter Joseph]

Stephen Smalley wrote:
>  
>  I think that just caused it to boot to runlevel 1, i.e. single-user
>  mode.  AFAIK, the kernel command line isn't used for booleans at all,
>  but an integer argument will be taken as the runlevel by init.
>  
>  -- 
>  Stephen Smalley
>  National Security Agency
>  
>  You are absolutely right - thanks for bringing this to my attention (as I
>  said before, I am quite new to Linux).
>  This does, however, bring up a security question.  It seems to me that by
>  editing the end of the kernel line at grub prompt to contain "1" can
>  compromise the system by turning over the entire control.  As long as
>  someone has access to an idle machine, local or remote, there is no way it
>  can be protected (perhaps by using the boot-loader password - will have to
>  try that).
>  
>  --
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>  
>   
-- 
View this message in context:
http://www.nabble.com/SELinux-Reset-tp24855587p24907209.html
Sent from the Fedora SELinux List mailing list archive at Nabble.com.