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, 08:16 PM
Mr Dash Four
 
Default SELinux and Shorewall with IPSets

>> 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.
>
I definitely will, though I am encouraged that I may not need to do the
relabelling after all as I have just ran freshly built image with
SELinux=Enforced and without shorewall/ipset installed (so that they
don't create unnecessary problems) through qemu and it ran happily - no
problems. Will see how it goes in practice, fingers crossed.

> Otherwise wait a day when the professionals can reply to your query.
>
Haha! No worries, I am glad there are still people left in the community
willing to give you a hand when needed (besides, there is no guarantee
that these 'professionals' as you put it would be able to help out -
I've ran across all sorts in my career).

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

>> 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.
>
I did and everything works to absolute perfection!

I couldn't help but try it myself. Both "semodule -i" and "restorecon
-rivvF /" (this is what I executed to relabel the whole file system - is
that right?) ran without any difficulties and did the job as expected.
When I later on mounted the image and logged in using qemu everything
was there as expected (semodule -lv shows the newly installed module and
I also ran cross checks on the SELinux file attributes to see whether
they were changed with "ls -Z" and they have).

There is a slight drawback to all of this though - for some (well, most
really) processes I use non-standard ports (another security measure I
have taken onboard and implemented). sshd for example is not listening
on the 'standard' port (tcp/22), but on a different one and this causes
SELinux to issue "denied { name_bind }" alert. Also, my syslog-ng is
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.

So, I am guessing I need to grab a good SELinux book and start reading
before making alterations to the (standard) SELinux policies. I also
take it, altering the relevant (default) policies is the best thing to
do in this case, is that right?

What documentation source would you recommend for this kind of job? As
all alterations will be done through the kickstart file I am going to
use command line tools only - no GUI!
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-28-2010, 07:55 AM
Dominick Grift
 
Default SELinux and Shorewall with IPSets

On 06/28/2010 03:00 AM, 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.
>>
> I did and everything works to absolute perfection!
>
> I couldn't help but try it myself. Both "semodule -i" and "restorecon
> -rivvF /" (this is what I executed to relabel the whole file system - is
> that right?) ran without any difficulties and did the job as expected.
> When I later on mounted the image and logged in using qemu everything
> was there as expected (semodule -lv shows the newly installed module and
> I also ran cross checks on the SELinux file attributes to see whether
> they were changed with "ls -Z" and they have).

sudo restorecon -R -v should usually be suffice.
The -F (force) option is to force customizable types to be reset.
Customizable types are types defined to not relabel by default

> There is a slight drawback to all of this though - for some (well, most
> really) processes I use non-standard ports (another security measure I
> have taken onboard and implemented). sshd for example is not listening
> on the 'standard' port (tcp/22), but on a different one and this causes
> SELinux to issue "denied { name_bind }" alert. Also, my syslog-ng is


For example if ssh bind tcp sockets to port 11000:

sudo semanage port -a -t ssh_port_t -p tcp 11000

> 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)

> So, I am guessing I need to grab a good SELinux book and start reading
> before making alterations to the (standard) SELinux policies. I also
> take it, altering the relevant (default) policies is the best thing to
> do in this case, is that right?

That is what i do, i maintain my own fork of selinux-policy.

> What documentation source would you recommend for this kind of job? As
> all alterations will be done through the kickstart file I am going to
> use command line tools only - no GUI!

www.selinuxbyexample.com

By the best doc, uptodate and all, is the source policy. writing policy
isnt so hard but theres a lot of it usually. and if you focus on the
amount of rules then its easy to think that stuff is complex.

If you take away all the types, then it boils down to the core, which
are type statements, classes, attributes, types, interfaces, templates,
permissions, permission sets, and a few mpre of those things. You can
learn all about those by just studying the source policy.
www.selinuxproject.org also has some nice docs.

> --
> 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-28-2010, 06:40 PM
Stephen Smalley
 
Default SELinux and Shorewall with IPSets

On Sun, 2010-06-27 at 13:37 +0100, Mr Dash Four wrote:
> 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.

ipset does appear to create and use a raw IP socket based on a quick
look at its source code. You could have also confirmed that by
strace'ing it or enabling syscall audit.

ipset isn't part of Fedora, right? You just built and installed it from
source?

I think it might be easiest to just label it the same as iptables and
then shorewall will transition to iptables_t which already has raw IP
socket access as well as other related permissions. That will be better
too in that you don't need to directly allow shorewall or anything else
it runs in-domain to have those permissions.

semanage fcontext -a -t iptables_exec_t /path/to/ipset
restorecon -v /path/to/ipset

--
Stephen Smalley
National Security Agency

--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-28-2010, 06:51 PM
Stephen Smalley
 
Default SELinux and Shorewall with IPSets

On Sun, 2010-06-27 at 21:26 +0200, Dominick Grift wrote:
> 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.

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.

--
Stephen Smalley
National Security Agency

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

> ipset isn't part of Fedora, right?
Wrong!

It is distributed as rpm in the Fedora Fusion (Free) repo (3 rpms in
fact: kmod-xtables-addons, xtables-addons and one additional package -
optional - xtables addons with metadata for kernel).

> You just built and installed it from source?
>
Please read my initial post - installing the above packages (i.e. the
'standard' distribution) makes NO difference whatsoever - I was getting
the same alerts regardless of whether I compile and install from source
or use the 'standard' distribution packages.

> I think it might be easiest to just label it the same as iptables and
> then shorewall will transition to iptables_t which already has raw IP
> socket access as well as other related permissions. That will be better
> too in that you don't need to directly allow shorewall or anything else
> it runs in-domain to have those permissions.
>
> semanage fcontext -a -t iptables_exec_t /path/to/ipset
> restorecon -v /path/to/ipset
>
An elegant solution ... but unfortunately it does NOT work - I am
getting the same alerts again.

The problem (as evident from my initial post on this thread) is that the
shorewall init file (normally based in /etc/shorewall/init) executes
ipset, which in turn, as you pointed out above, tries to open a raw
socket. I am in no way SELinux expert, but I would assume that the
security context in which this executes is shorewall and not the one set
in ipset.

Anyway, the solution presented by Dominic above works very well, so I
may stick with it.
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-28-2010, 11:35 PM
Mr Dash Four
 
Default SELinux and Shorewall with IPSets

>>> 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!
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-28-2010, 11:42 PM
Mr Dash Four
 
Default SELinux and Shorewall with IPSets

>> I did and everything works to absolute perfection!
>>
>> I couldn't help but try it myself. Both "semodule -i" and "restorecon
>> -rivvF /" (this is what I executed to relabel the whole file system - is
>> that right?) ran without any difficulties and did the job as expected.
>> When I later on mounted the image and logged in using qemu everything
>> was there as expected (semodule -lv shows the newly installed module and
>> I also ran cross checks on the SELinux file attributes to see whether
>> they were changed with "ls -Z" and they have).
>>
>
> sudo restorecon -R -v should usually be suffice.
> The -F (force) option is to force customizable types to be reset.
> Customizable types are types defined to not relabel by default
>
Noted, thanks.

>> There is a slight drawback to all of this though - for some (well, most
>> really) processes I use non-standard ports (another security measure I
>> have taken onboard and implemented). sshd for example is not listening
>> on the 'standard' port (tcp/22), but on a different one and this causes
>> SELinux to issue "denied { name_bind }" alert. Also, my syslog-ng is
>>
>
>
> 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?

>> 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.

>> What documentation source would you recommend for this kind of job? As
>> all alterations will be done through the kickstart file I am going to
>> use command line tools only - no GUI!
>>
>
> www.selinuxbyexample.com
>
> By the best doc, uptodate and all, is the source policy. writing policy
> isnt so hard but theres a lot of it usually. and if you focus on the
> amount of rules then its easy to think that stuff is complex.
>
> If you take away all the types, then it boils down to the core, which
> are type statements, classes, attributes, types, interfaces, templates,
> permissions, permission sets, and a few mpre of those things. You can
> learn all about those by just studying the source policy.
> www.selinuxproject.org also has some nice docs.
>
Noted, many thanks!

I am really liking this - today tried to execute "semodule -lv >
loaded_modules.txt" (as root and pwd -> /root) and instantly got an
alert - semodule was prevented from creating that file! Lovely stuff!
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 06-29-2010, 08:41 AM
Dominick Grift
 
Default SELinux and Shorewall with IPSets

On 06/29/2010 01:42 AM, Mr Dash Four wrote:
>
>>> I did and everything works to absolute perfection!
>>>
>>> I couldn't help but try it myself. Both "semodule -i" and "restorecon
>>> -rivvF /" (this is what I executed to relabel the whole file system - is
>>> that right?) ran without any difficulties and did the job as expected.
>>> When I later on mounted the image and logged in using qemu everything
>>> was there as expected (semodule -lv shows the newly installed module and
>>> I also ran cross checks on the SELinux file attributes to see whether
>>> they were changed with "ls -Z" and they have).
>>>
>>
>> sudo restorecon -R -v should usually be suffice.
>> The -F (force) option is to force customizable types to be reset.
>> Customizable types are types defined to not relabel by default
>>
> Noted, thanks.
>
>>> There is a slight drawback to all of this though - for some (well, most
>>> really) processes I use non-standard ports (another security measure I
>>> have taken onboard and implemented). sshd for example is not listening
>>> on the 'standard' port (tcp/22), but on a different one and this causes
>>> SELinux to issue "denied { name_bind }" alert. Also, my syslog-ng is
>>>
>>
>>
>> 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.

>>> 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.
>
>>> What documentation source would you recommend for this kind of job? As
>>> all alterations will be done through the kickstart file I am going to
>>> use command line tools only - no GUI!
>>>
>>
>> www.selinuxbyexample.com
>>
>> By the best doc, uptodate and all, is the source policy. writing policy
>> isnt so hard but theres a lot of it usually. and if you focus on the
>> amount of rules then its easy to think that stuff is complex.
>>
>> If you take away all the types, then it boils down to the core, which
>> are type statements, classes, attributes, types, interfaces, templates,
>> permissions, permission sets, and a few mpre of those things. You can
>> learn all about those by just studying the source policy.
>> www.selinuxproject.org also has some nice docs.
>>
> Noted, many thanks!
>
> I am really liking this - today tried to execute "semodule -lv >
> loaded_modules.txt" (as root and pwd -> /root) and instantly got an
> alert - semodule was prevented from creating that file! Lovely stuff!

Exactly my thought.

> --
> 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-29-2010, 12:03 PM
Stephen Smalley
 
Default SELinux and Shorewall with IPSets

On Tue, 2010-06-29 at 00:30 +0100, Mr Dash Four wrote:
> > I think it might be easiest to just label it the same as iptables and
> > then shorewall will transition to iptables_t which already has raw IP
> > socket access as well as other related permissions. That will be better
> > too in that you don't need to directly allow shorewall or anything else
> > it runs in-domain to have those permissions.
> >
> > semanage fcontext -a -t iptables_exec_t /path/to/ipset
> > restorecon -v /path/to/ipset
> >
> An elegant solution ... but unfortunately it does NOT work - I am
> getting the same alerts again.
>
> The problem (as evident from my initial post on this thread) is that the
> shorewall init file (normally based in /etc/shorewall/init) executes
> ipset, which in turn, as you pointed out above, tries to open a raw
> socket. I am in no way SELinux expert, but I would assume that the
> security context in which this executes is shorewall and not the one set
> in ipset.

# sesearch --type -s shorewall_t -t iptables_exec_t
Found 1 semantic te rules:
type_transition shorewall_t iptables_exec_t : process iptables_t;

The policy defines a transition from shorewall_t to iptables_t upon
executing a binary labeled with iptables_exec_t. So when shorewall
invokes iptables, it transitions to the right domain. Labeling ipset in
the same manner would yield the same effect for it.

As a simulation, I did this:
$ cp /usr/bin/id ./myipset
$ chcon -t iptables_exec_t ./myipset
$ setenforce 0
$ runcon system_u:system_r:shorewall_t:s0 /bin/bash -c ./myipset

And it correctly reported that myipset was running in iptables_t.

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?

> Anyway, the solution presented by Dominic above works very well, so I
> may stick with it.

--
Stephen Smalley
National Security Agency

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

Thread Tools




All times are GMT. The time now is 11:56 PM.

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