can not boot with strict policy

can not boot with strict policy

[Ken YANG]

hi all:

i run in FC7 Rawhide with strict policy, which is built from svn
refpolicy:

TYPE = strict-mcs
DIRECT_INITRC=y
MONOLITHIC=n
MLS_SENS=16
MLS_CATS=1024
MCS_CATS=1024

after i loaded the policy:

make && make install && make load && \
"modify /etc/selinux/config to use new policy" && \
touch /.autorelabel


and reboot, but "kernel panic" occur:

"......
avc: denied {execute} for pid=1 comm="init" name="libsepol.so.1"
scontext=system_u:system_r:init_t:s0 tcontext=user_u:object_r:lib_t:s0
tclass=file
Kernel panic - not syncing: Attempted to kill init!
......"


i think the reason of above "execute error" is due to the following
policy:

allow files_unconfined_type file_type:{ file chr_file } ~execmod;
......
ifdef(`targeted_policy',`
	unconfined_domain(init_t)
')
......
files_type(lib_t)



is that right?

i made some tests, in which i removed the "targed_policy" conditions.
the "execute error" disappear, but there are more avc denied during
init process, and after following avc denied, the system restarting:

"
avc: denied { execute } ... comm="init" name="/lib/libblkid.so.1.0"
Restarting system.
"


i don't know what's wrong with my method?

thanks in advance


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: can not boot with strict policy

[Stephen Smalley]

On Mon, 2007-04-23 at 20:09 +0800, Ken YANG wrote:
> hi all:
> 
> i run in FC7 Rawhide with strict policy, which is built from svn
> refpolicy:
> 
> TYPE = strict-mcs
> DIRECT_INITRC=y
> MONOLITHIC=n
> MLS_SENS=16
> MLS_CATS=1024
> MCS_CATS=1024
> 
> after i loaded the policy:
> 
> make && make install && make load && \
> "modify /etc/selinux/config to use new policy" && \
> touch /.autorelabel
> 
> 
> and reboot, but "kernel panic" occur:
> 
> "......
> avc: denied {execute} for pid=1 comm="init" name="libsepol.so.1"
> scontext=system_u:system_r:init_t:s0 tcontext=user_u:object_r:lib_t:s0
> tclass=file

/lib/libsepol.so.1 should be labeled with shlib_t, not lib_t.  Under
targeted policy, they are aliases for one another.  Under strict, they
are separate types.

Boot with "enforcing=0 single" to come up permissive into single-user
mode, then run /sbin/fixfiles relabel -F to forcible relabel everything,
then reboot.

Of course, I assume you have set the other build.conf settings
appropriately for Fedora.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: can not boot with strict policy

[James Morris]

On Mon, 23 Apr 2007, Stephen Smalley wrote:

> /lib/libsepol.so.1 should be labeled with shlib_t, not lib_t.  Under
> targeted policy, they are aliases for one another.  Under strict, they
> are separate types.
> 
> Boot with "enforcing=0 single" to come up permissive into single-user
> mode, then run /sbin/fixfiles relabel -F to forcible relabel everything,
> then reboot.

I wonder if we could automate this, so that the autorelabel is also run 
on boot if you switch between different types of policy.

-- 
James Morris
<jmorris@namei.org>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: can not boot with strict policy

[Stephen Smalley]

On Mon, 2007-04-23 at 13:42 -0400, James Morris wrote:
> On Mon, 23 Apr 2007, Stephen Smalley wrote:
> 
> > /lib/libsepol.so.1 should be labeled with shlib_t, not lib_t.  Under
> > targeted policy, they are aliases for one another.  Under strict, they
> > are separate types.
> > 
> > Boot with "enforcing=0 single" to come up permissive into single-user
> > mode, then run /sbin/fixfiles relabel -F to forcible relabel everything,
> > then reboot.
> 
> I wonder if we could automate this, so that the autorelabel is also run 
> on boot if you switch between different types of policy.

rc.sysinit does have autorelabel support, but that won't help in this
case, because here everything (including /sbin/init) will fail to run
due to the inability to execute shared libs.  It would have to happen
from early userspace or /sbin/init before loading policy and switching
to enforcing mode.

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: can not boot with strict policy

[Daniel J Walsh]

Stephen Smalley wrote:
> On Mon, 2007-04-23 at 13:42 -0400, James Morris wrote:
>   
>> On Mon, 23 Apr 2007, Stephen Smalley wrote:
>>
>>     
>>> /lib/libsepol.so.1 should be labeled with shlib_t, not lib_t.  Under
>>> targeted policy, they are aliases for one another.  Under strict, they
>>> are separate types.
>>>
>>> Boot with "enforcing=0 single" to come up permissive into single-user
>>> mode, then run /sbin/fixfiles relabel -F to forcible relabel everything,
>>> then reboot.
>>>       
>> I wonder if we could automate this, so that the autorelabel is also run 
>> on boot if you switch between different types of policy.
>>     
>
> rc.sysinit does have autorelabel support, but that won't help in this
> case, because here everything (including /sbin/init) will fail to run
> due to the inability to execute shared libs.  It would have to happen
> from early userspace or /sbin/init before loading policy and switching
> to enforcing mode.
>
>   
So the real question, is there much value with the division between 
lib_t and shlib_t.
When dealing with strict policy, shared libraries were always getting 
mislabeled as lib_t, and causing problems, for little security advantage. 

As we remove the differences between strict and targeted, I don't intend 
to get rid of lib_t == shlib_t.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: can not boot with strict policy

[Ken YANG]

Daniel J Walsh wrote:
> Stephen Smalley wrote:
>> On Mon, 2007-04-23 at 13:42 -0400, James Morris wrote:
>>  
>>> On Mon, 23 Apr 2007, Stephen Smalley wrote:
>>>
>>>    
>>>> /lib/libsepol.so.1 should be labeled with shlib_t, not lib_t.  Under
>>>> targeted policy, they are aliases for one another.  Under strict, they
>>>> are separate types.
>>>>
>>>> Boot with "enforcing=0 single" to come up permissive into single-user
>>>> mode, then run /sbin/fixfiles relabel -F to forcible relabel 
>>>> everything,
>>>> then reboot.
>>>>       
>>> I wonder if we could automate this, so that the autorelabel is also 
>>> run on boot if you switch between different types of policy.
>>>     
>>
>> rc.sysinit does have autorelabel support, but that won't help in this
>> case, because here everything (including /sbin/init) will fail to run
>> due to the inability to execute shared libs.  It would have to happen
>> from early userspace or /sbin/init before loading policy and switching
>> to enforcing mode.

in such situation, we will have "kernel panic" each time when changing
from "targeted" to "strict", aren't we?

there muse be some methods to solve this problems.

>>
>>   
> So the real question, is there much value with the division between 
> lib_t and shlib_t.
> When dealing with strict policy, shared libraries were always getting 
> mislabeled as lib_t, and causing problems, for little security advantage.
> As we remove the differences between strict and targeted, I don't intend 
> to get rid of lib_t == shlib_t.


i find most files labeled with "lib_t" are ".a" or symbolic link to
".so"

what difference between lib_t and shlib_t? what is the purpose of
"lib_t" type?

> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: can not boot with strict policy

[Daniel J Walsh]

Ken YANG wrote:
> Daniel J Walsh wrote:
>> Stephen Smalley wrote:
>>> On Mon, 2007-04-23 at 13:42 -0400, James Morris wrote:
>>>  
>>>> On Mon, 23 Apr 2007, Stephen Smalley wrote:
>>>>
>>>>   
>>>>> /lib/libsepol.so.1 should be labeled with shlib_t, not lib_t.  Under
>>>>> targeted policy, they are aliases for one another.  Under strict, 
>>>>> they
>>>>> are separate types.
>>>>>
>>>>> Boot with "enforcing=0 single" to come up permissive into single-user
>>>>> mode, then run /sbin/fixfiles relabel -F to forcible relabel 
>>>>> everything,
>>>>> then reboot.
>>>>>       
>>>> I wonder if we could automate this, so that the autorelabel is also 
>>>> run on boot if you switch between different types of policy.
>>>>     
>>>
>>> rc.sysinit does have autorelabel support, but that won't help in this
>>> case, because here everything (including /sbin/init) will fail to run
>>> due to the inability to execute shared libs.  It would have to happen
>>> from early userspace or /sbin/init before loading policy and switching
>>> to enforcing mode.
>
> in such situation, we will have "kernel panic" each time when changing
> from "targeted" to "strict", aren't we?
>
> there muse be some methods to solve this problems.
>
When converting from targeted to strict, your first boot has to be done 
in permissive mode, to let the relabel occur.  After the relabel, you 
can go to enforcing mode.  Some people have put out examples of how to 
do this in a kick start.  This  is the way the MLS kickstart works.
>>>
>>>   
>> So the real question, is there much value with the division between 
>> lib_t and shlib_t.
>> When dealing with strict policy, shared libraries were always getting 
>> mislabeled as lib_t, and causing problems, for little security 
>> advantage.
>> As we remove the differences between strict and targeted, I don't 
>> intend to get rid of lib_t == shlib_t.
>
>
> i find most files labeled with "lib_t" are ".a" or symbolic link to
> ".so"
>
> what difference between lib_t and shlib_t? what is the purpose of
> "lib_t" type?
>
>>
lib_t is the default label for all files in /lib (/usr/lib, var/lib, 
...) directories that are not shared libraries


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: can not boot with strict policy

[Christopher J. PeBenito]

On Tue, 2007-04-24 at 16:11 +0800, Ken YANG wrote:
> Daniel J Walsh wrote:
> > So the real question, is there much value with the division between 
> > lib_t and shlib_t.
> > When dealing with strict policy, shared libraries were always getting 
> > mislabeled as lib_t, and causing problems, for little security advantage.
> > As we remove the differences between strict and targeted, I don't intend 
> > to get rid of lib_t == shlib_t.
> 
> 
> i find most files labeled with "lib_t" are ".a" or symbolic link to
> ".so"
> 
> what difference between lib_t and shlib_t? what is the purpose of
> "lib_t" type?

The difference boils down to being able to mmap shlib_t files as
executable (which is required for shared libraries to work), whereas
that is not allowed for lib_t files.  That means that only shared
libraries are shlib_t and symlinks and static libraries (and other
random files placed in /lib or /usr/lib) are lib_t.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: can not boot with strict policy

[Ken YANG]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030; format=flowed, Size: 1755 bytes --]

Christopher J. PeBenito wrote:
> On Tue, 2007-04-24 at 16:11 +0800, Ken YANG wrote:
>> Daniel J Walsh wrote:
>>> So the real question, is there much value with the division between 
>>> lib_t and shlib_t.
>>> When dealing with strict policy, shared libraries were always getting 
>>> mislabeled as lib_t, and causing problems, for little security advantage.
>>> As we remove the differences between strict and targeted, I don't intend 
>>> to get rid of lib_t == shlib_t.
>>
>> i find most files labeled with "lib_t" are ".a" or symbolic link to
>> ".so"
>>
>> what difference between lib_t and shlib_t? what is the purpose of
>> "lib_t" type?
> 
> The difference boils down to being able to mmap shlib_t files as
> executable (which is required for shared libraries to work), whereas
> that is not allowed for lib_t files.  That means that only shared
> libraries are shlib_t and symlinks and static libraries (and other
> random files placed in /lib or /usr/lib) are lib_t.


the problem is due to my fault, rebooting with strict policy without
relabel in permissive mode.

in my opinion, the distinction between lib_t and shlib_t in strict
policy should be kept, we can not regards all libs as same with share
libraries.

we can avoid this "denial problems" by writing corresponding
informations in manual. In many situations, switching from targeted
to strict is a "big" changes, only certain people will perform this
kind of operation, and i guess these people will also study the manual,
before administrate SELinux system.



> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: can not boot with strict policy

[Christopher J. PeBenito]

On Mon, 2007-04-23 at 14:14 -0400, Daniel J Walsh wrote:
> So the real question, is there much value with the division between 
> lib_t and shlib_t.
> When dealing with strict policy, shared libraries were always getting 
> mislabeled as lib_t, and causing problems, for little security advantage. 

In Gentoo I don't see these kinds of problems, and we still have the
strict policy as the default option (until recently on desktops) and I
don't see this problem; the fc regexes work very well.  However, the
Gentoo community is far smaller than Fedora/RHEL.

> As we remove the differences between strict and targeted, I don't intend 
> to get rid of lib_t == shlib_t.

I had intended to drop the alias, so i guess we need more discussion. :)

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: can not boot with strict policy

[Stephen Smalley]

On Tue, 2007-04-24 at 12:23 +0000, Christopher J. PeBenito wrote:
> On Mon, 2007-04-23 at 14:14 -0400, Daniel J Walsh wrote:
> > So the real question, is there much value with the division between 
> > lib_t and shlib_t.
> > When dealing with strict policy, shared libraries were always getting 
> > mislabeled as lib_t, and causing problems, for little security advantage. 
> 
> In Gentoo I don't see these kinds of problems, and we still have the
> strict policy as the default option (until recently on desktops) and I
> don't see this problem; the fc regexes work very well.  However, the
> Gentoo community is far smaller than Fedora/RHEL.
> 
> > As we remove the differences between strict and targeted, I don't intend 
> > to get rid of lib_t == shlib_t.
> 
> I had intended to drop the alias, so i guess we need more discussion. :)

There were definitely problems with shared objects showing up as lib_t
in Fedora, so I suppose the question is what security benefit do we
derive from maintaining the shlib_t vs. lib_t distinction (and the same
question could be applied for many of the "system" types).  

-- 
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: can not boot with strict policy

[Daniel J Walsh]

Christopher J. PeBenito wrote:
> On Mon, 2007-04-23 at 14:14 -0400, Daniel J Walsh wrote:
>   
>> So the real question, is there much value with the division between 
>> lib_t and shlib_t.
>> When dealing with strict policy, shared libraries were always getting 
>> mislabeled as lib_t, and causing problems, for little security advantage. 
>>     
>
> In Gentoo I don't see these kinds of problems, and we still have the
> strict policy as the default option (until recently on desktops) and I
> don't see this problem; the fc regexes work very well.  However, the
> Gentoo community is far smaller than Fedora/RHEL.
>
>   
The problems happen when people use tools like cp/tar and other tools to 
put libraries on the system.  So the question I put out is the value of 
being able to stop mmap a non shared library, give you a security 
benefit, versus the hassle of a denial, because of a mislabeled shared 
library.
I look at this the same way as bin_t/sbin_t, it might have made sense 
theoretically but in practice it added little/no security value.
>> As we remove the differences between strict and targeted, I don't intend 
>> to get rid of lib_t == shlib_t.
>>     
>
> I had intended to drop the alias, so i guess we need more discussion. :)
>
>   


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: can not boot with strict policy

[Russell Coker]

On Tuesday 24 April 2007 03:42, James Morris <jmorris@namei.org> wrote:
> > Boot with "enforcing=0 single" to come up permissive into single-user
> > mode, then run /sbin/fixfiles relabel -F to forcible relabel everything,
> > then reboot.
>
> I wonder if we could automate this, so that the autorelabel is also run
> on boot if you switch between different types of policy.

There are a few ways of doing this.  For my Kickstart configuration of MLS 
systems and Play machines I used to create an /etc/init.d script that would 
put the machine in enforcing mode and configure grub with enforcing=1 and 
then put enforcing=0 on the grub command-line before the final reboot of the 
install.

For a more general solution you might want to have /sbin/init search 
for /.changing-policy-type as a reason to boot in permissive mode.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: can not boot with strict policy

[Ken YANG]

Russell Coker wrote:
> On Tuesday 24 April 2007 03:42, James Morris <jmorris@namei.org> wrote:
>>> Boot with "enforcing=0 single" to come up permissive into single-user
>>> mode, then run /sbin/fixfiles relabel -F to forcible relabel everything,
>>> then reboot.
>> I wonder if we could automate this, so that the autorelabel is also run
>> on boot if you switch between different types of policy.
> 
> There are a few ways of doing this.  For my Kickstart configuration of MLS 
> systems and Play machines I used to create an /etc/init.d script that would 
> put the machine in enforcing mode and configure grub with enforcing=1 and 
> then put enforcing=0 on the grub command-line before the final reboot of the 
> install.
> 
> For a more general solution you might want to have /sbin/init search 
> for /.changing-policy-type as a reason to boot in permissive mode.


the general solution sounds good, which can make the process
automatically like the ".autorelabel" way.

by the way, changing policy from targeted to strict also had other
problems in FC. I am not sure whether the problem occurred in other
distribution too.

before rc.sysinit executes, "/dev" has the "tmpfs_t" type because:

fs_use_trans tmpfs gen_context(system_u:object_r:tmpfs_t,s0);

only after rc.sysinit executed, "/dev" had been relabel to "device_t":

if [ -n "$SELINUX_STATE" -a -x /sbin/restorecon ] && LC_ALL=C fgrep -q " 
/dev " /proc/mounts ; then
         /sbin/restorecon  -R /dev 2>/dev/null
fi

so there is the problem:

avc: denied {search} for pid=1 comm="init" name="/" dev=tmpfs ino=824
scontext=system_u:system_r:init_t:s0
tcontext=system_u:object_r:tmpfs_t:s0 tclass=dir

the "name" field in avc messages is obscure, i deduce the conclusion
from the inode that the target is "/dev", not "/"

but if "distro_redhat" tunables had not been turned on, init will not
have search and other permission to perform certain operations on
tmpfs_t

but because my policy is from svn, the default value of DISTRO
is null.

i doubt whether other distribution has the same problem?
are there some measures to avoid this kind of problem? because
not everyone, especially newbie like me, can figure out this part.


additionally, i am using the "te.vim" from Thomas Bleher to make
te file highlight, but i also want to make fc and if file highlight.
any guides? except SLIDE



> 


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: can not boot with strict policy

[Russell Coker]

On Monday 23 April 2007 22:09, Ken YANG <spng.yang@gmail.com> wrote:
> make && make install && make load && \
> "modify /etc/selinux/config to use new policy" && \
> touch /.autorelabel
>
>
> and reboot, but "kernel panic" occur:
>
> "......
> avc: denied {execute} for pid=1 comm="init" name="libsepol.so.1"
> scontext=system_u:system_r:init_t:s0 tcontext=user_u:object_r:lib_t:s0
> tclass=file
> Kernel panic - not syncing: Attempted to kill init!

Did you try booting in permissive mode?  The process of converting from 
targeted to strict is not well tested and not guaranteed to work in enforcing 
mode.

-- 
russell@coker.com.au
http://etbe.blogspot.com/          My Blog

http://www.coker.com.au/sponsorship.html Sponsoring Free Software development

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.