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?
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
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?
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
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@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
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
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@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
On Fri, Aug 7, 2009 at 6:08 PM, Peter Josephpeterjb@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?
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
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@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
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
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@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
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@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?
On Mon, Aug 10, 2009 at 7:45 AM, Stephen Smalleysds@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@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.
On 08/10/2009 09:06 AM, max bianco wrote:
On Mon, Aug 10, 2009 at 7:45 AM, Stephen Smalleysds@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@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?
On Mon, Aug 10, 2009 at 9:55 AM, Daniel J Walshdwalsh@redhat.com wrote:
On 08/10/2009 09:06 AM, max bianco wrote:
On Mon, Aug 10, 2009 at 7:45 AM, Stephen Smalleysds@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@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@mail.com 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
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
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.
Daniel J Walsh wrote:
On 08/10/2009 09:06 AM, max bianco wrote:
On Mon, Aug 10, 2009 at 7:45 AM, Stephen Smalleysds@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@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@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
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 Smalleysds@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@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@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.
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.
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.
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 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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-selinux-list
selinux@lists.fedoraproject.org