SELinux question

[Paul Howarth]

Zoltan Boszormenyi wrote:
> Paul Howarth írta:
>> You must have auditd running (probably a system upgraded from FC4 rather
>> than a clean FC5 install).
>>   
> 
> Actually, no. I was a clean install over my previous FC3.
> I installed and set auditd to run.

OK. I do this myself too, but most people don't...

>> Set yourself up for making local policy modules:
...
>> Make a local policy module for this issue, in this directory:
>> 1. Create a file postgres.te with this content:
>>
>> module postgres 0.1;
...
>>
>> 2. Create a file postgres.fc with this content:
>>
>> /home1/pgsql[^/]*/data(/.*)?
>> gen_context(system_u:object_r:postgresql_db_t,s0)
>>
>> /home1/pgsql[^/]*/pgstartup.log    --
>> gen_context(system_u:object_r:postgresql_log_t,s0)
>>
>> (that's two long lines)
...
>> Next, remove any file context objects you added for this issue using
>> semanage (contexts will now be managed using your local policy module):
>>
>> # semanage fcontext -d -t postgresql_db_t '/home1/pgsql/data(/.*)?'
>> # semanage fcontext -d -t postgresql_log_t '/home1/pgsql/pgstartup.log'
>> # semanage fcontext -d -t postgresql_db_t '/home1/pgsql2/data(/.*)?'
>>
>> Finally, install your new policy module:
>>
>> # semodule -i postgres.pp
>>   
> 
> Thanks, it almost worked. After doing these above,
> I still got avc denied { search } messages like this below:
> 
> type=AVC msg=audit(1148979521.381:10): avc:  denied  { search } for  
> pid=2666 comm="postmaster" name="/" dev=sda1 ino=2 
> scontext=system_u:system_r:postgresql_t:s0 
> tcontext=system_u:object_r:default_t:s0 tclass=dir
> 
> As it turned out, /home1 was default_t and postgresql is not enabled to 
> search
> and read files in default_t context. It made it working:
> 
> # semanage fcontext -a -t var_lib_t -f -d '/home1'
> # fixfiles relabel /home1

You can incorporate this into your local policy module by adding another 
line to postgres.fc:

/home1(/pgsql)? -d gen_context(system_u:object_r:var_lib_t,s0)

Bump the version number in postgres.te from 0.1 to 0.2 and re-run make.

You could then remove the extra fcontext object using semanage, and 
update the policy module:
# semodule -i postgres.pp

Having everything in the policy module is better for maintainability I 
think.

> What puzzled me is starting postgresql failed at boot
> but not the manual "service postgresql start" after bootup.
> (Maybe different contexts are applied to the logged-in root
> and the init program?)

Running the initscript should be exactly the same as the boot process. 
Starting the service manually (without the initscript) would be 
different though, as no domain transition would happen.

Do the AVCs logged during the boot process show the process running as 
postgresql_t? If you do a "ps uaxZ", is it running as postgresql_t or 
unconfined_t?

> The two lines above made it working again.

So it's working from bootup now?

>>>>>> An easier way is to bind mount /home/pgsql on /var/lib/pgsql etc. 
>>>>>> and do
>>>>>> a restorecon -R on the "new" /var/lib/pgsql. That achieves the same
>>>>>> effect without the symlink.
>>>>>>           
> 
> Actually I missed the "bind mount" part. That would have been much easier.
> But the crash course in SELinux was most fruitful, thank you.

I've just responded to another poster with almost exactly the same 
issue. I think this might be worth a wiki page.

> Sorry for the late answer, yesterday I donated my blood
> and had to hit the bed earlier that my usual.

No problem, we all have to sleep!

Cheers, Paul.