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