SELinux and Shorewall with IPSets

[Dominick Grift]

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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/selinux


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/selinux/attachments/20100628/c8cba998/attachment.bin