FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 12-06-2011, 09:16 PM
JB
 
Default Problem booting under F16

Daniel J Walsh <dwalsh <at> redhat.com> writes:

> ...
> SELinux relabeling is caused by booting a rescue mode kernel. As soon
> as you boot a system with SELinux disabled, the init system creates
> the /.autorelabel file, so the next time it boots with SELinux it will
> relabel.
>

Question:
Are you not setting yourself up for trouble with this /.autorelabel here ?

Case:
- I disable selinux
# cat /etc/sysconfig/selinux ...
SELINUX=disabled
- I reboot the system,
- /.autorelabel created by sys init,
- I enable selinux again,
- I reboot with intention to boot rescue mode kernel (obviously because I assume
there is some problem to fix; it would make sense to boot to the same system
state that caused me to want it have investigated or fixed, without e.g. any
potential interruption or fs changes, perhaps from selinux doing relabeling),
- Selinux jumps in with relabeling (potential interference/change to system
state as described above, it may not even finish its job, and so I am stuck
and unable to fix the system, now and possibly on next attempt as well).

Do you see a problem here ?

JB


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 12-07-2011, 01:11 AM
Marko Vojinovic
 
Default Problem booting under F16

On Tuesday 06 December 2011 22:16:40 JB wrote:
> Daniel J Walsh <dwalsh <at> redhat.com> writes:
> > ...
> > SELinux relabeling is caused by booting a rescue mode kernel. As soon
> > as you boot a system with SELinux disabled, the init system creates
> > the /.autorelabel file, so the next time it boots with SELinux it will
> > relabel.
>
> Question:
> Are you not setting yourself up for trouble with this /.autorelabel here ?
>
> Case:
> - I disable selinux
> # cat /etc/sysconfig/selinux ...
> SELINUX=disabled
> - I reboot the system,
> - /.autorelabel created by sys init,
> - I enable selinux again,
> - I reboot with intention to boot rescue mode kernel (obviously because I
> assume there is some problem to fix; it would make sense to boot to the
> same system state that caused me to want it have investigated or fixed,
> without e.g. any potential interruption or fs changes, perhaps from selinux
> doing relabeling), - Selinux jumps in with relabeling (potential
> interference/change to system state as described above, it may not even
> finish its job, and so I am stuck and unable to fix the system, now and
> possibly on next attempt as well).
>
> Do you see a problem here ?

I see a problem with a second-to-last step in your list.

If you have a broken system which needs rescuing, and it has SELinux disabled
to begin with, why would you want to enable it just before getting into rescue
mode?

And if you actually do have a reason to enable it and then rescue the system,
you'd better let it relabel, or else you are in for a very fun ride with your
rescue operation...

This is one of the reasons why I don't like the option to disable SELinux
completely. If you leave it in permissive mode, it will keep out of your way
while keeping proper file labelling. Thus no problems can arise if you ever
want to enforce SELinux again.

Disabling SELinux completely makes sense only on HPC clusters and similar,
where every bit of CPU time should be squeezed out, where SELinux has a
nontrivial CPU/FS footprint, and where security is not an issue so that its
footprint is useless. The rule of thumb is --- disable SELinux only on systems
where you are absolutely certain that you will never ever ever want to
reenable it again. On everything else keep it in enforcing or permissive, and
you won't get into inconvenient-relabeling-time problems.

HTH, :-)
Marko


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 12-07-2011, 05:09 AM
JB
 
Default Problem booting under F16

Marko Vojinovic <vvmarko <at> gmail.com> writes:

> ...
> >
> > Case:
> > - I disable selinux
> > # cat /etc/sysconfig/selinux ...
> > SELINUX=disabled
> > - I reboot the system,
> > - /.autorelabel created by sys init,
> > - I enable selinux again,
> > - I reboot with intention to boot rescue mode kernel (obviously because I
> > assume there is some problem to fix; it would make sense to boot to the
> > same system state that caused me to want it have investigated or fixed,
> > without e.g. any potential interruption or fs changes, perhaps from selinux
> > doing relabeling), - Selinux jumps in with relabeling (potential
> > interference/change to system state as described above, it may not even
> > finish its job, and so I am stuck and unable to fix the system, now and
> > possibly on next attempt as well).
> >
> > Do you see a problem here ?
>
> I see a problem with a second-to-last step in your list.
>
> If you have a broken system which needs rescuing, and it has SELinux disabled
> to begin with, why would you want to enable it just before getting into
> rescue mode?

Yes, indeed, but it is not impossible.
I wanted to re-play (mechanically) a case reflecting Daniel's description.
And it seems to show a weak point.

> And if you actually do have a reason to enable it and then rescue the system,
> you'd better let it relabel, or else you are in for a very fun ride with your
> rescue operation...

That may be true on the surface, but as I already stated there is a danger
in selinux not finishing or getting stuck, altering system state to be
"rescued" (investigated or fixed).

> ...
Yes, your other remarks regarding selinux are valid.

JB


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 12-07-2011, 07:14 AM
JB
 
Default Problem booting under F16

JB <jb.1234abcd <at> gmail.com> writes:

> ...

To make my point clear.

In general, the resuce mode turns all services off for the purpose of preserving
the original troubled environment (machine state) and preventing any worsening
of it until it can be investigated or fixed.

So it seems a rescue mode should not allow execution of selinux relabeling
right before it, under any circumstances.

JB


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 12-07-2011, 12:43 PM
Daniel J Walsh
 
Default Problem booting under F16

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/07/2011 03:14 AM, JB wrote:
> JB <jb.1234abcd <at> gmail.com> writes:
>
>> ...
>
> To make my point clear.
>
> In general, the resuce mode turns all services off for the purpose
> of preserving the original troubled environment (machine state) and
> preventing any worsening of it until it can be investigated or
> fixed.
>
> So it seems a rescue mode should not allow execution of selinux
> relabeling right before it, under any circumstances.
>
> JB
>
>
My understanding is when you are in rescue mode SELinux should be
disabled and no relabeling should take place. What does happen is the
flag gets set (/.autorelabel). So theoretically when you reboot the
machine with SELinux enabled, the first thing it will do is make sure
all the labels are correct so SELinux will work properly. If you see
a system that you boot in rescue mode trying to relabel, then I would
guess this is a bug.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7fbWUACgkQrlYvE4MpobPyhACfXDKOCMZsbf K1zaIWbT0K2zWo
/V0AoJmj+PZeyQgu0YF5xMNAjEvb8ztP
=Qks/
-----END PGP SIGNATURE-----
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 12-07-2011, 01:53 PM
JB
 
Default Problem booting under F16

Daniel J Walsh <dwalsh <at> redhat.com> writes:

>
>
> On 12/07/2011 03:14 AM, JB wrote:
> > JB <jb.1234abcd <at> gmail.com> writes:
> >
> >> ...
> >
> > To make my point clear.
> >
> > In general, the resuce mode turns all services off for the purpose
> > of preserving the original troubled environment (machine state) and
> > preventing any worsening of it until it can be investigated or
> > fixed.
> >
> > So it seems a rescue mode should not allow execution of selinux
> > relabeling right before it, under any circumstances.
> >
> > JB
> >
> >
> My understanding is when you are in rescue mode SELinux should be
> disabled and no relabeling should take place. What does happen is the
> flag gets set (/.autorelabel). So theoretically when you reboot the
> machine with SELinux enabled, the first thing it will do is make sure
> all the labels are correct so SELinux will work properly. If you see
> a system that you boot in rescue mode trying to relabel, then I would
> guess this is a bug.
>

OK. We are on the same page with regard to the principle:
In rescue mode SELinux should be disabled and no relabeling should take place.

But the issue is how to enforce it.
You say "should be", but I showed in that Case scenario that I constructed
few posts above that SELinux can be enabled by chance (sysadmin is doing her
job, there are problems, boom, ...), followed by reboot to rescue mode, which
gets preceded by actual relabeling due to SELinux being enabled as above.

I would like to see it enforced "the hard way", so that the principle does not
get violated by chance or even intention (at least easily via selinux config
file or manual entry).

I thought about using unit file directive(s) to do that, making relabeling
serice and emergency or rescue services (targets) mutually exclusive.

I am not an expert on systemd :-) but it seems that
Conflicts=
and
ConflictedBy=
can do the job.

Can that be done ?

JB


--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 12-07-2011, 02:31 PM
Daniel J Walsh
 
Default Problem booting under F16

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/07/2011 09:53 AM, JB wrote:
> Daniel J Walsh <dwalsh <at> redhat.com> writes:
>
>>
>>
>> On 12/07/2011 03:14 AM, JB wrote:
>>> JB <jb.1234abcd <at> gmail.com> writes:
>>>
>>>> ...
>>>
>>> To make my point clear.
>>>
>>> In general, the resuce mode turns all services off for the
>>> purpose of preserving the original troubled environment
>>> (machine state) and preventing any worsening of it until it can
>>> be investigated or fixed.
>>>
>>> So it seems a rescue mode should not allow execution of
>>> selinux relabeling right before it, under any circumstances.
>>>
>>> JB
>>>
>>>
>> My understanding is when you are in rescue mode SELinux should
>> be disabled and no relabeling should take place. What does
>> happen is the flag gets set (/.autorelabel). So theoretically
>> when you reboot the machine with SELinux enabled, the first thing
>> it will do is make sure all the labels are correct so SELinux
>> will work properly. If you see a system that you boot in rescue
>> mode trying to relabel, then I would guess this is a bug.
>>
>
> OK. We are on the same page with regard to the principle: In rescue
> mode SELinux should be disabled and no relabeling should take
> place.
>
> But the issue is how to enforce it. You say "should be", but I
> showed in that Case scenario that I constructed few posts above
> that SELinux can be enabled by chance (sysadmin is doing her job,
> there are problems, boom, ...), followed by reboot to rescue mode,
> which gets preceded by actual relabeling due to SELinux being
> enabled as above.
>
> I would like to see it enforced "the hard way", so that the
> principle does not get violated by chance or even intention (at
> least easily via selinux config file or manual entry).
>
> I thought about using unit file directive(s) to do that, making
> relabeling serice and emergency or rescue services (targets)
> mutually exclusive.
>
> I am not an expert on systemd :-) but it seems that Conflicts= and
> ConflictedBy= can do the job.
>
> Can that be done ?
>
> JB
>
>
I thought the rescure kernel would boot with selinux=0. I am no
expert on systemd either. Perhaps should discuss on systemd list.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7fhsgACgkQrlYvE4MpobOBEACgnv63IYoM/qR6JXHvLVB66PnH
Jt8AmgNSUPT2nAT8Rbfv+A2gP06yNk/c
=KGal
-----END PGP SIGNATURE-----
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 
Old 12-10-2011, 11:42 PM
Joe Zeff
 
Default Problem booting under F16

On 11/27/2011 06:13 AM, Sam Varshavchik wrote:
>
> Again, I'd suggest uninstalling the most recent kernel, and reinstalling
> it, in order to regenerate the initrd, and the grub menu item for it,
> afresh.

I haven't quite done that, but I have something new to report. The
following is quoted from a post on fedoraforum.org, to avoid retyping:

I just now noticed something that might be significant: if I boot from
either of the fc16 kernels, boot gets to:

Started Loading Random Seed

then goes back to:

Starting LSB

and this time it hands when it's trying a second time to recreate the
Volatile Files and Directories. Also, in my current grub2.cfg, there are
two inetrd lines for each fc16 kernel, but if I take either out by
boot-time editing, it fails even worse.
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
 

Thread Tools




All times are GMT. The time now is 05:03 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org