Re: SELinux and Shorewall with IPSets

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



  

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


[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux