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 SELinux Support

 
 
LinkBack Thread Tools
 
Old 06-29-2010, 12:12 PM
Stephen Smalley
 
Default SELinux and Shorewall with IPSets

On Tue, 2010-06-29 at 00:35 +0100, Mr Dash Four wrote:
> >>> Is that a necessary thing to do after installing a new module? My
> >>> understanding is that relabelling only corrects the SELinux file
> >>> attributes on every file on the system, so why would I need to do the
> >>> relabelling when I have just installed a new policy?
> >>>
> >>> Also, if my assumption is correct then why would I need to have a
> >>> running SELinux to do that? It is a great inconvenience and a real pain
> >>> for scenarios I described in my previous posts!
> >>>
> >> Good points. i think you might indeed be able to run restorecon or
> >> fixfiles/setfiles in %post, but i am not sure.
> >>
> >> I would suggest you try it.
> >>
> >> Otherwise wait a day when the professionals can reply to your query.
> >>
> >
> > restorecon exits immediately if SELinux is disabled, so you cannot use
> > it to label a tree on a non-SELinux build host. Dan wanted it that way
> > so that he could unconditionally invoke it from scripts and not have it
> > do anything if SELinux was disabled.
> >
> > setfiles however does support labeling even on a non-SELinux host. As
> > well as labeling an image that is being built with a "foreign" (i.e.
> > different from host) policy on a SELinux host, although you have to run
> > it in setfiles_mac_t for that purpose, as the livecd-creator does.
> >
> Actually, I did execute restorecon on a non-SELinux running image (see
> previous posts on this very thread) and it worked pretty damn well!
>
> It works without me doing anything in particular - just executing
> restorecon and semodule in the %post section of the kickstart file - no
> problem!

rpm -q -f `which restorecon`
grep selinuxfs /proc/filesystems

restorecon checks is_selinux_enabled() and bails if it is not
successful. Just tested it again on F13, and it has been true for a
very long time.

--
Stephen Smalley
National Security Agency

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-29-2010, 01:22 PM
Mr Dash Four
 
Default SELinux and Shorewall with IPSets

> So I'm curious as to why this isn't working for you. Did the restorecon
> command in fact change the label of the program to iptables_exec_t? Did
> you get the same AVC message as before?
>
>
Exactly the same message - no difference!

I am willing to investigate this further to get to the bottom of it.
When I do not have my custom .pp and FC tries to start the shorewall
service it fails (sometimes it gives me the alert, some times it
doesn't). When I try to execute "service shorewall start" (as root) it
always fails and always gives me those alerts (as I mentioned they are
exactly the same, but I will have a closer look again). I will post
these logs again (+ what I am doing/executing) when I have the chance to
get to it - later today may be.
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-29-2010, 01:35 PM
Mr Dash Four
 
Default SELinux and Shorewall with IPSets

>> Actually, I did execute restorecon on a non-SELinux running image (see
>> previous posts on this very thread) and it worked pretty damn well!
>>
>> It works without me doing anything in particular - just executing
>> restorecon and semodule in the %post section of the kickstart file - no
>> problem!
>>
>
> rpm -q -f `which restorecon`
> grep selinuxfs /proc/filesystems
>
> restorecon checks is_selinux_enabled() and bails if it is not
> successful. Just tested it again on F13, and it has been true for a
> very long time
Let me make sure we are on the same page - the SELinux on the system I
am running to build the image is enabled (in enforced mode) and running
the targeted policy.

The commands I am executing (semodule, semanage, restorecon etc) are ran
in the %post section of my kickstart file (the file, which is executed
and used to build that image) - these commands are basically executed in
chroot-ed environment (on the image file) just after it has been created
and all software, including SELinux + targeted policy, is installed (the
SELinux there is enabled and ready for using the targeted policy, but it
is NOT running as nothing is loaded - it is just an image with about
200+MB worth of files in it).

All of the above SELinux commands run successfully without any problem
whatsoever.

I have verified that and I am 100% certain they are doing the job they
are supposed to be doing on the image file (with the 'dead' SELinux
system). So, if you are thinking that is not possible, you are quite
simply wrong, because it is clear to me that is not the case - I saw
this with my own eyes!
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-29-2010, 01:41 PM
Stephen Smalley
 
Default SELinux and Shorewall with IPSets

On Tue, 2010-06-29 at 14:35 +0100, Mr Dash Four wrote:
> >> Actually, I did execute restorecon on a non-SELinux running image (see
> >> previous posts on this very thread) and it worked pretty damn well!
> >>
> >> It works without me doing anything in particular - just executing
> >> restorecon and semodule in the %post section of the kickstart file - no
> >> problem!
> >>
> >
> > rpm -q -f `which restorecon`
> > grep selinuxfs /proc/filesystems
> >
> > restorecon checks is_selinux_enabled() and bails if it is not
> > successful. Just tested it again on F13, and it has been true for a
> > very long time
> Let me make sure we are on the same page - the SELinux on the system I
> am running to build the image is enabled (in enforced mode) and running
> the targeted policy.

Oh, so SELinux is enabled.

> The commands I am executing (semodule, semanage, restorecon etc) are ran
> in the %post section of my kickstart file (the file, which is executed
> and used to build that image) - these commands are basically executed in
> chroot-ed environment (on the image file) just after it has been created
> and all software, including SELinux + targeted policy, is installed (the
> SELinux there is enabled and ready for using the targeted policy, but it
> is NOT running as nothing is loaded - it is just an image with about
> 200+MB worth of files in it).

Sure, but the question of SELinux enablement is merely one of whether
the running kernel has SELinux enabled and a policy loaded. As your
build host is running with SELinux enabled, restorecon will run for you,
even within the chroot, although it might need proc mounted within the
chroot to determine the SELinux status.

> All of the above SELinux commands run successfully without any problem
> whatsoever.
>
> I have verified that and I am 100% certain they are doing the job they
> are supposed to be doing on the image file (with the 'dead' SELinux
> system). So, if you are thinking that is not possible, you are quite
> simply wrong, because it is clear to me that is not the case - I saw
> this with my own eyes!

restorecon will run as long as it sees that SELinux is enabled, which in
this case it is. But if you were in fact building the image on a
SELinux-disabled host, you'd have to use setfiles instead.

Another interesting case is when SELinux is enabled on the build host
but using a very different policy than the image you are building,
including file security contexts that aren't even defined in the build
host's policy. They had to solve that issue for livecd-creator.

--
Stephen Smalley
National Security Agency

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-29-2010, 09:56 PM
Mr Dash Four
 
Default SELinux and Shorewall with IPSets

> So I'm curious as to why this isn't working for you. Did the restorecon
> command in fact change the label of the program to iptables_exec_t? Did
> you get the same AVC message as before?
>
OK, I did the following after "semanage fcontext -a -t iptables_exec_t
/usr/sbin/ipset" and "restorecon -v /usr/sbin/ipset":

[root@dev1 ~]# sesearch --type -s shorewall_t -t iptables_exec_t
Found 1 semantic te rules:
type_transition shorewall_t iptables_exec_t : process iptables_t;

[root@dev1 ~]# ls -lasZ /usr/sbin/ipset
-rwxr-xr-x. root root system_ubject_r:iptables_exec_t:s0 /usr/sbin/ipset

[root@dev1 ~]# service shorewall start
Starting Shorewall: [FAILED]

==============syslog============================== ==========================
Jun 29 22:42:01 dev1 shorewall[2667]: Compiling...
Jun 29 22:42:02 dev1 kernel: type=1400 audit(1277847722.204:30394):
avc: denied { create } for pid=2790 comm="ipset"
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 29 22:42:02 dev1 kernel: type=1400 audit(1277847722.207:30395):
avc: denied { create } for pid=2792 comm="ipset"
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 29 22:42:02 dev1 shorewall[2667]: Compiling /etc/shorewall/zones...
Jun 29 22:42:02 dev1 shorewall[2667]: Compiling /etc/shorewall/interfaces...
Jun 29 22:42:02 dev1 shorewall[2667]: Determining Hosts in Zones...
Jun 29 22:42:02 dev1 shorewall[2667]: Preprocessing Action Files...
Jun 29 22:42:02 dev1 shorewall[2667]: Pre-processing
/usr/share/shorewall/action.Drop...
Jun 29 22:42:02 dev1 shorewall[2667]: Pre-processing
/usr/share/shorewall/action.Reject...
Jun 29 22:42:02 dev1 shorewall[2667]: Compiling /etc/shorewall/policy...
Jun 29 22:42:02 dev1 shorewall[2667]: Compiling /etc/shorewall/blacklist...
Jun 29 22:42:02 dev1 shorewall[2667]: ERROR: ipset names in Shorewall
configuration files require Ipset Match in your kernel and iptables :
/etc/shorewall/blacklist (line 11)
Jun 29 22:42:02 dev1 shorewall[2667]: ERROR:Shorewall start failed
================================================== ==============================


So, as you can see it clearly does NOT work for some reason! Applying my
own/patched policy module (myshorewall.pp) does the trick. Any suggestions?
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-30-2010, 11:10 AM
Mr Dash Four
 
Default SELinux and Shorewall with IPSets

> So I'm curious as to why this isn't working for you. Did the restorecon
> command in fact change the label of the program to iptables_exec_t? Did
> you get the same AVC message as before?
>
Mystery solved! I've had an inspiration this morning.

At the time I installed ipset at least 2 times (from Fedora Fusion as
well as compiling it from source), so I assumed ipset was installed in
the same location. 'whereis ipset' revealed that I have TWO copies: one
in /sbin and another one (which I have 'used' up until now) in
/usr/sbin. So, for some reason, even though I specified the executable
in /usr/sbin to be executed in my shorewall init (the one with the
'right' SELinux attributes) the executable in /sbin must have been
picked somehow. When I removed the copy in /sbin and then rebooted - all
was well and shorewall ran without any problems. Bizarre!
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-30-2010, 04:12 PM
Mr Dash Four
 
Default SELinux and Shorewall with IPSets

>>> For example if ssh bind tcp sockets to port 11000:
>>>
>>> sudo semanage port -a -t ssh_port_t -p tcp 11000
>>>
>>>
>> Is this type "ssh_port_t" something, which is already registered (as
>> part of the targeted policy perhaps?) and I am just modifying it or is
>> this not the case?
>>
>>
>
> Yes ssh_port_t is the ssh port type. tcp;22 is labelled with type
> ssh_port_t, we just label tcp:11000 ssh_port_t so that ssh can bind tcp
> sockets to that port as well.
>
Well, I do not wish to keep the tcp/22 as part of the policy (if left,
it creates a loophole!). I tried "semanage port -m -t ssh_port_t -p tcp
222" (to modify it), but got "/usr/sbin/semanage: Port tcp/222 is not
defined". I then added tcp/222 as you suggested and then tried to
execute "semanage port -d -t ssh_port_t -p tcp 22" to remove the tcp/22
part, but got this: "/usr/sbin/semanage: Port tcp/22 is defined in
policy, cannot be deleted". What does that mean exactly?

>>>> using a directory, which maps to a non-standard directory (through
>>>> symbolic link - /var/log is a symbolic link to a different/secure
>>>> partition of the disk) and that also causes "denied { read }" with
>>>> "tclass=lnk_file" alert.
>>>>
>>>>
>>> This will require a patch (need more info : avc denials of this event)
>>>
>>>
>> I will post it separately as when I run the image with qemu cutting and
>> pasting is not as straightforward.
>>
type=1400 audit(1277908958.656.4): avc: denied { read } for pid=906
comm="rsyslogd" name="log" dev=dm-0 ino=16386
scontext=system_u:system_r:syslogd_t:s0
tcontext=unconfined_ubject_r:var_t:s0 tclass=lnk_file

There is a similar one with "mingetty" as well, but
scontext=system_u:system_r:getty_t:s0
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-30-2010, 04:19 PM
Dominick Grift
 
Default SELinux and Shorewall with IPSets

On 06/30/2010 06:12 PM, Mr Dash Four wrote:
>
>>>> For example if ssh bind tcp sockets to port 11000:
>>>>
>>>> sudo semanage port -a -t ssh_port_t -p tcp 11000
>>>>
>>> Is this type "ssh_port_t" something, which is already registered (as
>>> part of the targeted policy perhaps?) and I am just modifying it or
>>> is this not the case?
>>>
>>>
>>
>> Yes ssh_port_t is the ssh port type. tcp;22 is labelled with type
>> ssh_port_t, we just label tcp:11000 ssh_port_t so that ssh can bind tcp
>> sockets to that port as well.
>>
> Well, I do not wish to keep the tcp/22 as part of the policy (if left,
> it creates a loophole!). I tried "semanage port -m -t ssh_port_t -p tcp
> 222" (to modify it), but got "/usr/sbin/semanage: Port tcp/222 is not
> defined". I then added tcp/222 as you suggested and then tried to
> execute "semanage port -d -t ssh_port_t -p tcp 22" to remove the tcp/22
> part, but got this: "/usr/sbin/semanage: Port tcp/22 is defined in
> policy, cannot be deleted". What does that mean exactly?

It means that the corenetwork module (which is compiled into the base
module) has a port object context specification for type ssh_port_t --
tcp:22

So you would have edit that in the main selinux-policy package.

>
>>>>> using a directory, which maps to a non-standard directory (through
>>>>> symbolic link - /var/log is a symbolic link to a different/secure
>>>>> partition of the disk) and that also causes "denied { read }" with
>>>>> "tclass=lnk_file" alert.
>>>>>
>>>> This will require a patch (need more info : avc denials of this event)
>>>>
>>> I will post it separately as when I run the image with qemu cutting
>>> and pasting is not as straightforward.
>>>
> type=1400 audit(1277908958.656.4): avc: denied { read } for pid=906
> comm="rsyslogd" name="log" dev=dm-0 ino=16386
> scontext=system_u:system_r:syslogd_t:s0
> tcontext=unconfined_ubject_r:var_t:s0 tclass=lnk_file
>
> There is a similar one with "mingetty" as well, but
> scontext=system_u:system_r:getty_t:s0

This symlink is mislabeled. What/who created it? if you , yourself
created it, then you may be able to make things work by labeling the
symlink type bin_t or type var_log_t, provided that the source of the
interaction (in this case syslogd_t and getty_t) have access to the
target of the symlink.

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-30-2010, 04:35 PM
Mr Dash Four
 
Default SELinux and Shorewall with IPSets

>> Well, I do not wish to keep the tcp/22 as part of the policy (if left,
>> it creates a loophole!). I tried "semanage port -m -t ssh_port_t -p tcp
>> 222" (to modify it), but got "/usr/sbin/semanage: Port tcp/222 is not
>> defined". I then added tcp/222 as you suggested and then tried to
>> execute "semanage port -d -t ssh_port_t -p tcp 22" to remove the tcp/22
>> part, but got this: "/usr/sbin/semanage: Port tcp/22 is defined in
>> policy, cannot be deleted". What does that mean exactly?
>>
>
> It means that the corenetwork module (which is compiled into the base
> module) has a port object context specification for type ssh_port_t --
> tcp:22
>
> So you would have edit that in the main selinux-policy package.
>
How do I do that? I looked at /usr/share/selinux/targeted, but could not
see anything, which could be edited.

>> type=1400 audit(1277908958.656.4): avc: denied { read } for pid=906
>> comm="rsyslogd" name="log" dev=dm-0 ino=16386
>> scontext=system_u:system_r:syslogd_t:s0
>> tcontext=unconfined_ubject_r:var_t:s0 tclass=lnk_file
>>
>> There is a similar one with "mingetty" as well, but
>> scontext=system_u:system_r:getty_t:s0
>>
>
> This symlink is mislabeled. What/who created it? if you , yourself
> created it, then you may be able to make things work by labeling the
> symlink type bin_t or type var_log_t, provided that the source of the
> interaction (in this case syslogd_t and getty_t) have access to the
> target of the symlink.
>
I did create it - it was done during the image build (it is empty, but
it links to a separate/secure partition on the target machine).
Relabelling worked though, I had to link the actual partition in order
to make it work!
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-30-2010, 04:45 PM
Dominick Grift
 
Default SELinux and Shorewall with IPSets

On 06/30/2010 06:35 PM, Mr Dash Four wrote:
>
>>> Well, I do not wish to keep the tcp/22 as part of the policy (if left,
>>> it creates a loophole!). I tried "semanage port -m -t ssh_port_t -p tcp
>>> 222" (to modify it), but got "/usr/sbin/semanage: Port tcp/222 is not
>>> defined". I then added tcp/222 as you suggested and then tried to
>>> execute "semanage port -d -t ssh_port_t -p tcp 22" to remove the tcp/22
>>> part, but got this: "/usr/sbin/semanage: Port tcp/22 is defined in
>>> policy, cannot be deleted". What does that mean exactly?
>>>
>>
>> It means that the corenetwork module (which is compiled into the base
>> module) has a port object context specification for type ssh_port_t --
>> tcp:22
>>
>> So you would have edit that in the main selinux-policy package.
>>
> How do I do that? I looked at /usr/share/selinux/targeted, but could not
> see anything, which could be edited.

You would need to edit the source, and rebuild modified selinux-policy
packages. The port declaration is located in
policy/modules/kernel/corenetwork.te.in.

In the following example it is on line 192:

http://oss.tresys.com/projects/refpolicy/browser/policy/modules/kernel/corenetwork.te.in

To modify it you would:

download the selinux-policy.src.rpm corresponding to the version you
have installed.

extract the source rpm.

extract the serefpolicy.tgz that is included in the source rpm.

apply the "*.patch" that is included in the source rpm

make your modifications

edit the selinux-policy.spec that is included with the source rpm.
Remove any reference to the patch. You have just applied it.

repackage the serefpolicy directory (create the same serefpolicy.tgz but
this time with patch applied and modification applied)

copy the contents to ~/rpmbuild/SOURCES/ (exclude the patch since it is
already applied)

copy the selinux-policy.spec to ~/rpmbuild/SPECS

run: rpmbuild -ba ~/rpmbuild/SPECS/selinux-policy.spec

install the modified/created selinux-policy and selinux-policy-targeted
rpms.

>>> type=1400 audit(1277908958.656.4): avc: denied { read } for pid=906
>>> comm="rsyslogd" name="log" dev=dm-0 ino=16386
>>> scontext=system_u:system_r:syslogd_t:s0
>>> tcontext=unconfined_ubject_r:var_t:s0 tclass=lnk_file
>>>
>>> There is a similar one with "mingetty" as well, but
>>> scontext=system_u:system_r:getty_t:s0
>>>
>>
>> This symlink is mislabeled. What/who created it? if you , yourself
>> created it, then you may be able to make things work by labeling the
>> symlink type bin_t or type var_log_t, provided that the source of the
>> interaction (in this case syslogd_t and getty_t) have access to the
>> target of the symlink.
>>
> I did create it - it was done during the image build (it is empty, but
> it links to a separate/secure partition on the target machine).
> Relabelling worked though, I had to link the actual partition in order
> to make it work!


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 

Thread Tools




All times are GMT. The time now is 09:29 PM.

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