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-27-2010, 12:37 PM
Mr Dash Four
 
Default SELinux and Shorewall with IPSets

Problems combining these 2 to run while SELinux is in 'enforced' mode
(policy running is the 'stock' targeted one supplied with FC13). I get 2
audit alerts when Shorewall starts (and fails!) - see logs below. I have
x86_64 arch machine with FC13 running. Stock Shorewall is installed.
IPSet (xtunnels) is compiled in (though with the 'stock' rpm I am
getting the same errors).

The problem seems to be caused by the Shorewall init script (see further
below). The relevant part of my syslog when SELinux is in enforced mode is:

=========SELinux=Enforcing======================== ========
Jun 26 23:18:38 dev1 shorewall[2456]: Compiling...
Jun 26 23:18:38 dev1 kernel: type=1400 audit(1277590718.634:29543):
avc: denied { create } for pid=2577 comm="ipset"
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 26 23:18:38 dev1 kernel: type=1400 audit(1277590718.637:29544):
avc: denied { create } for pid=2579 comm="ipset"
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/zones...
Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/interfaces...
Jun 26 23:18:38 dev1 shorewall[2456]: Determining Hosts in Zones...
Jun 26 23:18:38 dev1 shorewall[2456]: Preprocessing Action Files...
Jun 26 23:18:38 dev1 shorewall[2456]: Pre-processing
/usr/share/shorewall/action.Drop...
Jun 26 23:18:38 dev1 shorewall[2456]: Pre-processing
/usr/share/shorewall/action.Reject...
Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/policy...
Jun 26 23:18:38 dev1 shorewall[2456]: Compiling /etc/shorewall/blacklist...
Jun 26 23:18:38 dev1 shorewall[2456]: ERROR: ipset names in Shorewall
configuration files require Ipset Match in your kernel and iptables :
/etc/shorewall/blacklist (line 11)
Jun 26 23:18:38 dev1 shorewall[2456]: ERROR: Shorewall start failed
================================================== ========

When I switch SELinux to Permissive I get two further errors:

=========SELinux=Permissive======================= ========
Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29551):
avc: denied { create } for pid=3799 comm="ipset"
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29552):
avc: denied { getopt } for pid=3799 comm="ipset" lport=255
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 26 23:32:45 dev1 kernel: type=1400 audit(1277591565.629:29553):
avc: denied { setopt } for pid=3799 comm="ipset" lport=255
scontext=unconfined_u:system_r:shorewall_t:s0
tcontext=unconfined_u:system_r:shorewall_t:s0 tclass=rawip_socket
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/zones...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/interfaces...
Jun 26 23:32:45 dev1 shorewall[3678]: Determining Hosts in Zones...
Jun 26 23:32:45 dev1 shorewall[3678]: Preprocessing Action Files...
Jun 26 23:32:45 dev1 shorewall[3678]: Pre-processing
/usr/share/shorewall/action.Drop...
Jun 26 23:32:45 dev1 shorewall[3678]: Pre-processing
/usr/share/shorewall/action.Reject...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/policy...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/blacklist...
Jun 26 23:32:45 dev1 shorewall[3678]: Adding Anti-smurf Rules
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling TCP Flags filtering...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling Kernel Route Filtering...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling Martian Logging...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling MAC Filtration -- Phase 1...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling /etc/shorewall/rules...
Jun 26 23:32:45 dev1 shorewall[3678]: Generating Transitive Closure of
Used-action List...
Jun 26 23:32:45 dev1 shorewall[3678]: Processing
/usr/share/shorewall/action.Reject for chain Reject...
Jun 26 23:32:45 dev1 shorewall[3678]: Processing
/usr/share/shorewall/action.Drop for chain Drop...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling MAC Filtration -- Phase 2...
Jun 26 23:32:45 dev1 shorewall[3678]: Applying Policies...
Jun 26 23:32:45 dev1 shorewall[3678]: Generating Rule Matrix...
Jun 26 23:32:45 dev1 shorewall[3678]: Creating iptables-restore input...
Jun 26 23:32:45 dev1 shorewall[3678]: Compiling iptables-restore input
for chains blacklst mangle:...
Jun 26 23:32:45 dev1 shorewall[3678]: Shorewall configuration compiled
to /var/lib/shorewall/.start
Jun 26 23:32:45 dev1 shorewall[3678]: Starting Shorewall....
Jun 26 23:32:45 dev1 shorewall[3678]: Initializing...
Jun 26 23:32:46 dev1 kernel: u32 classifier
Jun 26 23:32:46 dev1 kernel: Performance counters on
Jun 26 23:32:46 dev1 kernel: input device check on
Jun 26 23:32:46 dev1 kernel: Actions configured
Jun 26 23:32:46 dev1 shorewall[3678]: Processing /etc/shorewall/init ...
Jun 26 23:32:46 dev1 shorewall[3678]: loading
/etc/shorewall/ips/blacklist-x1.ips
Jun 26 23:32:46 dev1 shorewall[3678]: loading
/etc/shorewall/ips/blacklist-x2.ips
Jun 26 23:32:46 dev1 shorewall[3678]: loading
/etc/shorewall/ips/blacklist-z1.ips
Jun 26 23:32:47 dev1 shorewall[3678]: loading
/etc/shorewall/ips/blacklist-z2.ips
Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/tcclear ...
Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Route Filtering...
Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Martian Logging...
Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Proxy ARP...
Jun 26 23:32:49 dev1 shorewall[3678]: Setting up Traffic Control...
Jun 26 23:32:49 dev1 shorewall[3678]: Preparing iptables-restore input...
Jun 26 23:32:49 dev1 shorewall[3678]: Running /sbin/iptables-restore...
Jun 26 23:32:49 dev1 shorewall[3678]: IPv4 Forwarding Enabled
Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/start ...
Jun 26 23:32:49 dev1 shorewall[3678]: Processing /etc/shorewall/started ...
Jun 26 23:32:49 dev1 shorewall[3678]: Shorewall started
================================================== ========

The problem seems to be caused by the shorewall init script, which is:

===========Shorewall init script==========================
modprobe ifb numifbs=1
ip link set dev ifb0 up

# configure the ipsets
sw_ips_mask='/etc/shorewall/ips/*.ips'
ipset_exec='/usr/sbin/ipset'
if [ "$COMMAND" = start ]; then
$ipset_exec -F
$ipset_exec -X
for c in `/bin/ls $sw_ips_mask 2>/dev/null`; do
echo loading $c
$ipset_exec -R < $c
done
fi
================================================== ========

The above script executes /usr/sbin/ipset to create my IP Sets needed
for running Shorewall (all IP set commands are contained in those *.ips
files). These IP sets comprise mainly of IP subnets which are part of my
blacklists (banned IP subnets), though they also contain some IP Port
sets as well.

Don't know why SELinux denies "create" (and then "getopt" and "setopt")
on a, what seems to be, raw ip socket (IPSet do not use/need one as far
as I know!)? If I remove the IP Set part of the init script above and
rearrange Shorewall to run without IPSets all is well, though its
functionality is VERY limited and barely useful to me!

Two questions to the SELinux gurus on here: 1) Why am I getting these
alerts? and 2) How can I fix the problem so that I could run both
Shorewall and IPSets with SELinux in Enforced mode?

This is important for me as this is a production server and a lot of
stuff runs on it and needs to be available 24/7.

Many thanks in advance!
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-27-2010, 12:44 PM
Dominick Grift
 
Default SELinux and Shorewall with IPSets

On 06/27/2010 02:37 PM, Mr Dash Four wrote:

> Two questions to the SELinux gurus on here: 1) Why am I getting these
> alerts? and 2) How can I fix the problem so that I could run both
> Shorewall and IPSets with SELinux in Enforced mode?


1) probably untested functionality.

2) The following should fix it:

mkdir ~/myshorewall; cd ~/myshorewall;
echo "policy_module(myshorewall, 1.0.0)" > myshorewall.te;
echo "optional_policy(`" >> myshorewall.te;
echo "gen_require(`" >> myshorewall.te;
echo "type shorewall_t;" >> myshorewall.te;
echo "')" >> myshorewall.te;
echo "allow shorewall_t self:rawip_socket create_socket_perms;" >>
myshorewall.te;
echo "')" >> myshorewall.te;

make -f /usr/share/selinux/devel/Makefile myshorewall.pp
sudo semodule -i myshorewall.pp

> This is important for me as this is a production server and a lot of
> stuff runs on it and needs to be available 24/7.
>
> Many thanks in advance!
> --
> selinux mailing list
> selinux@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux


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

>> Two questions to the SELinux gurus on here: 1) Why am I getting these
>> alerts? and 2) How can I fix the problem so that I could run both
>> Shorewall and IPSets with SELinux in Enforced mode?
>>
> 1) probably untested functionality.
>
> 2) The following should fix it:
>
Job done! It works now, though it was NOT a straight-forward job!

> make -f /usr/share/selinux/devel/Makefile myshorewall.pp
>
After executing this even though it all compiled OK I had an error at
the beginning telling me that /selinux/mls does not exist. That was
caused by SELinux being disabled (I did that as I was fed up with all
the alerts I was getting). I reinstated SELinux in Permissive mode,
re-labelled everything and then compiled this again - no error this
time. The above command created a lot of additional files though: .fc,
.if, as well as all_interfaces.conf, iferror.m4, .mod.role and .tmp
files (the last 4 files were placed in ~/myshorewall/tmp for some
reason) - do I need these files or should I delete them and just keep
the .pp file?

> sudo semodule -i myshorewall.pp
>
When I did that the module was installed, I rebooted, but this time I
started getting alerts popping all over the place from a lot of
processes running (alerts I did NOT have before). So, what I did then
was to do a relabelling again at reboot, but that did not work - still
alerts (not from shorewall though).

From experience (I had this happening before, so I know) - what I did
then was to uninstall the targeted policy package via yum (made sure I
disabled SELinux first!) AND did 'rm -rdf /etc/selinux/targeted' as
there were leftovers in that directory (don't know why, but the majority
of the stuff was there even though the policy is supposed to be removed
- may be this is an issue for the FC RPM admins/maintainers, I don't
know), rebooted, installed selinux-targeted-policy package again, did
"semodule -i myshorewall.pp", enabled SELinux (in Permissive mode first)
and finally did a relabelling at boot again.

Result - no alerts of any kind!

I am now in Enforced mode and everything is going OK so far, so many
thanks for the (very prompt) advice - much appreciated.

I have two more queries though - if I want to use this module (the .pp
file) on a system which is built from a ks file (using standard
kickstart tools) do I just copy myshorewall.pp to
/etc/selinux/targeted/modules/active/modules on the target system in
order to use this module? Would that be enough?

I also need to mention that the target system's root ('/') is
'read-only' in a sense that even though the content in it can be changed
it does NOT survive the boot (it is done as a unionfs of a ram disk and
the read-only system where all the files and programs are, so changes
get preserved in the ram part for the life of the session, but are gone
the next time the machine is rebooted) - this is done for extra security
and saved my neck on quite a few occasions!

Second query in relation to this - when I build the system can I do the
relabelling on the target system at the time when the image is built? If
so, how do I do that (ideally I would like to do that during the image
building process, in the %post section perhaps, of the .ks script)?

The reason for that is, as I put it above, the changes made once the
image is built are not preserved, and I do not want to be relabelling on
every reboot as it is too damn slow!


Thanks again!
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-27-2010, 04:57 PM
Dominick Grift
 
Default SELinux and Shorewall with IPSets

On 06/27/2010 06:40 PM, Mr Dash Four wrote:
> do I need these files or should I delete them and just keep
> the .pp file?


You do not really need to contents of ~/myshorewall after youve
built/installed the binary presentation (myshorewall.pp)

However it is a good idea to save the myshorewall.{te,if,fc} source
policy files, as you may want to extend it or just keep it for
reference. It may also be useful for your collegues.

>> sudo semodule -i myshorewall.pp
>>
> When I did that the module was installed, I rebooted, but this time I
> started getting alerts popping all over the place from a lot of
> processes running (alerts I did NOT have before). So, what I did then
> was to do a relabelling again at reboot, but that did not work - still
> alerts (not from shorewall though).

Never, ever disable SELinux. (atleast that is my opinion). You can also
configure SELinux to run in permissive mode. Which is basically a
interusion detection system as opposed to intrusing prevention system
(selinux in enforcing mode).

By using permissive mode, labeling should not mess up.

> From experience (I had this happening before, so I know) - what I did
> then was to uninstall the targeted policy package via yum (made sure I
> disabled SELinux first!) AND did 'rm -rdf /etc/selinux/targeted' as
> there were leftovers in that directory (don't know why, but the majority
> of the stuff was there even though the policy is supposed to be removed
> - may be this is an issue for the FC RPM admins/maintainers, I don't
> know), rebooted, installed selinux-targeted-policy package again, did
> "semodule -i myshorewall.pp", enabled SELinux (in Permissive mode first)
> and finally did a relabelling at boot again.
>
> Result - no alerts of any kind!
>
> I am now in Enforced mode and everything is going OK so far, so many
> thanks for the (very prompt) advice - much appreciated.
>

Yes in some cases de-installation of selinux-policy(-targeted), moving
/etc/selinux/targeted, and re-installation of selinux-policy(-targeted)
is the only way to fix some corruption. Always make sure to relabel
afterwards and also do not forget that local changes will be gone
(another good reason to keep the sources of your custom modules)

> I have two more queries though - if I want to use this module (the .pp
> file) on a system which is built from a ks file (using standard
> kickstart tools) do I just copy myshorewall.pp to
> /etc/selinux/targeted/modules/active/modules on the target system in
> order to use this module? Would that be enough?

No i do not think it will be enough (you would need sudo semodule -i
myshorewall.pp). But you should report your shorewall issue to bugzilla
so that it can be applied to the next selinux-policy package. This will
then make your customization no longer needed.

>
> I also need to mention that the target system's root ('/') is
> 'read-only' in a sense that even though the content in it can be changed
> it does NOT survive the boot (it is done as a unionfs of a ram disk and
> the read-only system where all the files and programs are, so changes
> get preserved in the ram part for the life of the session, but are gone
> the next time the machine is rebooted) - this is done for extra security
> and saved my neck on quite a few occasions!
>
> Second query in relation to this - when I build the system can I do the
> relabelling on the target system at the time when the image is built? If
> so, how do I do that (ideally I would like to do that during the image
> building process, in the %post section perhaps, of the .ks script)?
>
> The reason for that is, as I put it above, the changes made once the
> image is built are not preserved, and I do not want to be relabelling on
> every reboot as it is too damn slow!
>

You may (or may not) be able to edit dracut to relabel the filesystem on
each bootup (e.g.) generate an initramfs with the relabeling command.

Not exactly sure how to go about that but. you may be able to add it to
this file:
/usr/share/dracut/modules.d/99base/selinux-loadpolicy.sh
and then regenerate initrc (make sure the filesystem is mounted in the
chroot at the point of relabeling though)
/usr/libexec/plymouth/plymouth-update-initrd (unconfirmed)

> Thanks again!
> --
> selinux mailing list
> selinux@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux


--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-27-2010, 05:04 PM
Dominick Grift
 
Default SELinux and Shorewall with IPSets

On 06/27/2010 06:40 PM, Mr Dash Four wrote:

> I have two more queries though - if I want to use this module (the .pp
> file) on a system which is built from a ks file (using standard
> kickstart tools) do I just copy myshorewall.pp to
> /etc/selinux/targeted/modules/active/modules on the target system in
> order to use this module? Would that be enough?

You cannot simply copy it (need to install it (semodule -i). But you can
use a single binary presentation on most selinux enabled system (e.g.
deploy the single myshorewall.pp to various similar configured systems.)

all the modules in active/ are compiled into a policy database file
policy/policy.X.

If you just copy it to active it is not compiled into the actual policy
database yet.

>
> I also need to mention that the target system's root ('/') is
> 'read-only' in a sense that even though the content in it can be changed
> it does NOT survive the boot (it is done as a unionfs of a ram disk and
> the read-only system where all the files and programs are, so changes
> get preserved in the ram part for the life of the session, but are gone
> the next time the machine is rebooted) - this is done for extra security
> and saved my neck on quite a few occasions!
>
> Second query in relation to this - when I build the system can I do the
> relabelling on the target system at the time when the image is built? If
> so, how do I do that (ideally I would like to do that during the image
> building process, in the %post section perhaps, of the .ks script)?
>
> The reason for that is, as I put it above, the changes made once the
> image is built are not preserved, and I do not want to be relabelling on
> every reboot as it is too damn slow!
>
>
> Thanks again!
> --
> selinux mailing list
> selinux@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux


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

> On 06/27/2010 06:40 PM, Mr Dash Four wrote:
>
>
>> I have two more queries though - if I want to use this module (the .pp
>> file) on a system which is built from a ks file (using standard
>> kickstart tools) do I just copy myshorewall.pp to
>> /etc/selinux/targeted/modules/active/modules on the target system in
>> order to use this module? Would that be enough?
>>
>
> You cannot simply copy it (need to install it (semodule -i). But you can
> use a single binary presentation on most selinux enabled system (e.g.
> deploy the single myshorewall.pp to various similar configured systems.)
>
Does that mean if the policy is compiled on i686-based machine it can
then run/be deployed on a x86_64 and visa versa?

Also, does semodule need to have a running SELinux as I need to deploy
this module on a Linux system (image) which does NOT have SELinux
running (yet)?

In other words, if I issue this command in chroot-ed environment would
that be enough? The "%post" section of the kickstart file does just that
- it chroots to the image as it has been built and from there I can do
whatever I like on the actual image, though this is not a running system
- i.e. SELinux on that system is not loaded! If that is possible and if
I run on different architectures (say the image is for x86_64 and the
machine on which the image is built is i686) would it matter?

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-27-2010, 06:10 PM
Dominick Grift
 
Default SELinux and Shorewall with IPSets

On 06/27/2010 08:04 PM, Mr Dash Four wrote:
>
>> On 06/27/2010 06:40 PM, Mr Dash Four wrote:
>>
>>
>>> I have two more queries though - if I want to use this module (the .pp
>>> file) on a system which is built from a ks file (using standard
>>> kickstart tools) do I just copy myshorewall.pp to
>>> /etc/selinux/targeted/modules/active/modules on the target system in
>>> order to use this module? Would that be enough?
>>>
>>
>> You cannot simply copy it (need to install it (semodule -i). But you can
>> use a single binary presentation on most selinux enabled system (e.g.
>> deploy the single myshorewall.pp to various similar configured systems.)
>>
> Does that mean if the policy is compiled on i686-based machine it can
> then run/be deployed on a x86_64 and visa versa?

Yes policy is arch-independent.

> Also, does semodule need to have a running SELinux as I need to deploy
> this module on a Linux system (image) which does NOT have SELinux
> running (yet)?

Not sure, try it out.

> In other words, if I issue this command in chroot-ed environment would
> that be enough? The "%post" section of the kickstart file does just that
> - it chroots to the image as it has been built and from there I can do
> whatever I like on the actual image, though this is not a running system
> - i.e. SELinux on that system is not loaded! If that is possible and if
> I run on different architectures (say the image is for x86_64 and the
> machine on which the image is built is i686) would it matter?

The policy is arch-independent but i am not sure if it can be installed
on a system that has no selinux enabled. I think it is possible but i am
not sure.

You will still have the issue that you would have to relabel the
filesystem on each boot though.


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


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

>> I have two more queries though - if I want to use this module (the .pp
>> file) on a system which is built from a ks file (using standard
>> kickstart tools) do I just copy myshorewall.pp to
>> /etc/selinux/targeted/modules/active/modules on the target system in
>> order to use this module? Would that be enough?
>>
>
> No i do not think it will be enough (you would need sudo semodule -i
> myshorewall.pp).
See my previous response - I need to know whether I can use semodule on
a Linux system, which isn't running yet.

> But you should report your shorewall issue to bugzilla
> so that it can be applied to the next selinux-policy package. This will
> then make your customization no longer needed.
>
It is not that simple because xtables is an (unofficial) addon, which
has not yet been added to the ip(6)tables packages (though there are
plans to do that) and as of now it is distributed separately (nothing to
do with shorewall - it just uses it, as it does ip(6)tables). So, I am
hoping that ipset would become part of ip(6)tables and then, may be I
can remove my custom policy.

>> [relabelling]
>
> You may (or may not) be able to edit dracut to relabel the filesystem on
> each bootup (e.g.) generate an initramfs with the relabeling command.
>
> Not exactly sure how to go about that but. you may be able to add it to
> this file:
> /usr/share/dracut/modules.d/99base/selinux-loadpolicy.sh
> and then regenerate initrc (make sure the filesystem is mounted in the
> chroot at the point of relabeling though)
> /usr/libexec/plymouth/plymouth-update-initrd (unconfirmed)
>
OK, the whole reason I would like to do the relabelling is because I am
not sure that when the image is built and installed on the target
machine (with SELinux enforced!) I am not going to get lots of alerts
clogging my logs and preventing the system from operating just because
of labelling not done properly. As I am building this image from scratch
using kickstart tools, I do not know if I do not relabel the system I
won't get any alerts. I just want to be prepared for the worst case
scenario, that's all. If I do not get any alerts on the target system
after building and deploying the image, then all is well and this
relabelling business won't be needed - ever (as I already pointed out -
the target system will be read-only)!

Also, by placing '.relabel' (I think that was the file name) in the root
('/') directory this forces SELinux to relabel the whole system at
startup. As I mentioned before, if I need to do relabelling I would like
to do it when the image is built! I do not want to do that at every boot
(doing the relabelling when the target system boots would be a pointless
exercise as the changes won't be saved, so the next time I reboot I will
be at square 1 and the whole process will start again).

How is the relabelling done? Which program is used for that? If I start
that program from chroot-ed environment (from the %post section of my
kickstart file - see my previous reply) to relabel the whole image,
would that work?
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-27-2010, 06:37 PM
Mr Dash Four
 
Default SELinux and Shorewall with IPSets

>> Also, does semodule need to have a running SELinux as I need to deploy
>> this module on a Linux system (image) which does NOT have SELinux
>> running (yet)?
>>
>
> Not sure, try it out.
>
I will, though I have a gut feeling that it won't work as semodule may
be looking for a running SELinux database and I presume it picks up
policy (and files) from the running system. Will give it a try though!

>> In other words, if I issue this command in chroot-ed environment would
>> that be enough? The "%post" section of the kickstart file does just that
>> - it chroots to the image as it has been built and from there I can do
>> whatever I like on the actual image, though this is not a running system
>> - i.e. SELinux on that system is not loaded! If that is possible and if
>> I run on different architectures (say the image is for x86_64 and the
>> machine on which the image is built is i686) would it matter?
>>
>
> The policy is arch-independent but i am not sure if it can be installed
> on a system that has no selinux enabled. I think it is possible but i am
> not sure.
>
I'll give it a go!

> You will still have the issue that you would have to relabel the
> filesystem on each boot though.
>
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!
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-27-2010, 07:26 PM
Dominick Grift
 
Default SELinux and Shorewall with IPSets

On 06/27/2010 08:37 PM, Mr Dash Four wrote:
>
>>> Also, does semodule need to have a running SELinux as I need to deploy
>>> this module on a Linux system (image) which does NOT have SELinux
>>> running (yet)?
>>>
>>
>> Not sure, try it out.
>>
> I will, though I have a gut feeling that it won't work as semodule may
> be looking for a running SELinux database and I presume it picks up
> policy (and files) from the running system. Will give it a try though!
>
>>> In other words, if I issue this command in chroot-ed environment would
>>> that be enough? The "%post" section of the kickstart file does just that
>>> - it chroots to the image as it has been built and from there I can do
>>> whatever I like on the actual image, though this is not a running system
>>> - i.e. SELinux on that system is not loaded! If that is possible and if
>>> I run on different architectures (say the image is for x86_64 and the
>>> machine on which the image is built is i686) would it matter?
>>>
>>
>> The policy is arch-independent but i am not sure if it can be installed
>> on a system that has no selinux enabled. I think it is possible but i am
>> not sure.
>>
> I'll give it a go!
>
>> You will still have the issue that you would have to relabel the
>> filesystem on each boot though.
>>
> 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.

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


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

Thread Tools




All times are GMT. The time now is 04:18 PM.

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