SELinux question

[Zoltan Boszormenyi]

Paul Howarth írta:
> Zoltan Boszormenyi wrote:
>> Paul Howarth írta:
>>> 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.

You are right. Thanks.

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

Both

service postgresql start

and

su - postgres
PGDATA=/home1/pgsql pg_ctl start

started successfully if I logged in as root or under "su -" from my 
mortal uid.
(The postgresql initscript uses "runuser" instead of "su" IIRC.)

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

It's running under postgresql_t.

>> The two lines above made it working again.
>
> So it's working from bootup now?

Yes.

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

It would be a good idea.

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

Of course :-)

Best regards,
Zoltán Böszörményi