The policy was in play before installing the product, also why doesn't the pid file get labeled correctly?
Sent from my Windows Phone
Sent from my Windows Phone
From: Daniel J Walsh
Sent: 2/13/2014 6:58 PM
To: Jayson Hurst; selinux@xxxxxxxxxxxxxxxxxxxxxxx
Subject: Re: How to properly setup my domains security contexts in the domain.fc file?
On 02/13/2014 08:30 PM, Jayson Hurst wrote:
> I have a file context installed as follows:
>
> # semanage fcontext -l | grep vasd
>
> /etc/rc.d/init.d/vasd regular file
> system_u:object_r:vasd_initrc_exec_t:s0 /opt/quest/sbin/vasd regular file
> system_u:object_r:vasd_exec_t:s0 /var/opt/quest(/.*)? all files
> system_u:object_r:vasd_var_t:s0 /var/opt/quest/vas/vasd(/.*)? all files
> system_u:object_r:vasd_var_auth_t:s0 /var/opt/quest/vas/vasd/.vasd.pid
> regular file system_u:object_r:vasd_var_run_t:s0
>
> After a fresh install I see the following:
>
> # ls -laZ /var/opt/quest/vas/vasd/ drwxr-xr-x. root root
> unconfined_u:object_r:vasd_var_t:s0 . drwxr-xr-x. root root
> unconfined_u:object_r:vasd_var_t:s0 .. -rw-r--r--. root root
> unconfined_u:object_r:vasd_var_t:s0 vas_ident.vdb -rw-r--r--. root root
> unconfined_u:object_r:vasd_var_t:s0 vas_misc.vdb
>
>
> Why are the files being created under /var/opt/quest/vas/vasd not being
> labelled correctly as qasd_var_auth_t as the fcontext states? Is the
> software installer supposed to force a relabel on a post-install?
>
> After a restart of the daemon I do not see the pid file being labelled
> correctly:
>
> # /etc/init.d/vasd restart Stopping vasd: vasd does not appear to be
> running. Starting vasd: [ OK
> ]
>
> # ls -laZ /var/opt/quest/vas/vasd/ drwxr-xr-x. daemon daemon
> unconfined_u:object_r:vasd_var_t:s0 . drwxr-xr-x. root root
> unconfined_u:object_r:vasd_var_t:s0 .. srwxrwxrwx. daemon daemon
> unconfined_u:object_r:vasd_var_t:s0 .vasd_19574 srwxrwxrwx. daemon daemon
> unconfined_u:object_r:vasd_var_t:s0 .vasd_19575 srwxrwxrwx. daemon daemon
> unconfined_u:object_r:vasd_var_t:s0 .vasd_19576 srwxrwxrwx. daemon daemon
> unconfined_u:object_r:vasd_var_t:s0 .vasd40_ipc_sock -rw-r--r--. daemon
> daemon unconfined_u:object_r:vasd_var_t:s0 .vasd.pid -rw-r--r--. daemon
> daemon unconfined_u:object_r:vasd_var_t:s0 vas_ident.vdb -rw-r--r--.
> daemon daemon unconfined_u:object_r:vasd_var_t:s0 vas_misc.vdb
>
> After forcing a relabel:
>
> # restorecon -F -R /var/opt/quest/vas/vasd/
>
> # ls -laZ /var/opt/quest/vas/vasd/ drwxr-xr-x. daemon daemon
> system_u:object_r:vasd_var_auth_t:s0 . drwxr-xr-x. root root
> unconfined_u:object_r:vasd_var_t:s0 .. srwxrwxrwx. daemon daemon
> system_u:object_r:vasd_var_auth_t:s0 .vasd_19574 srwxrwxrwx. daemon daemon
> system_u:object_r:vasd_var_auth_t:s0 .vasd_19575 srwxrwxrwx. daemon daemon
> system_u:object_r:vasd_var_auth_t:s0 .vasd_19576 srwxrwxrwx. daemon daemon
> system_u:object_r:vasd_var_auth_t:s0 .vasd40_ipc_sock -rw-r--r--. daemon
> daemon system_u:object_r:vasd_var_auth_t:s0 .vasd.pid -rw-r--r--. daemon
> daemon system_u:object_r:vasd_var_auth_t:s0 vas_ident.vdb -rw-r--r--.
> daemon daemon system_u:object_r:vasd_var_auth_t:s0 vas_misc.vdb
>
> I get the files and directory labelled correctly, but not the pid file. I
> can set a pid transition in the policy but then what is the point of
> setting a file context in the <domain>.fc for the pid file if it never
> gets picked up? Apparently I am missing something important here.
>
> Does anyone know a place for good documentation on this subject?
>
>
>
>
>
>
>
> -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
If RPM puts the files on disk and then installs your policy in post install,
it will not fix the labels.
You could create an vasd-selinux.rpm and require this to be installed before
the vasd.rpm is installed. In that case the rpm should do the right thing, at
least on Fedora/RHEL7. Not sure about RHEL6.
Otherwise you can just run restorecon in the post install.
> I have a file context installed as follows:
>
> # semanage fcontext -l | grep vasd
>
> /etc/rc.d/init.d/vasd regular file
> system_u:object_r:vasd_initrc_exec_t:s0 /opt/quest/sbin/vasd regular file
> system_u:object_r:vasd_exec_t:s0 /var/opt/quest(/.*)? all files
> system_u:object_r:vasd_var_t:s0 /var/opt/quest/vas/vasd(/.*)? all files
> system_u:object_r:vasd_var_auth_t:s0 /var/opt/quest/vas/vasd/.vasd.pid
> regular file system_u:object_r:vasd_var_run_t:s0
>
> After a fresh install I see the following:
>
> # ls -laZ /var/opt/quest/vas/vasd/ drwxr-xr-x. root root
> unconfined_u:object_r:vasd_var_t:s0 . drwxr-xr-x. root root
> unconfined_u:object_r:vasd_var_t:s0 .. -rw-r--r--. root root
> unconfined_u:object_r:vasd_var_t:s0 vas_ident.vdb -rw-r--r--. root root
> unconfined_u:object_r:vasd_var_t:s0 vas_misc.vdb
>
>
> Why are the files being created under /var/opt/quest/vas/vasd not being
> labelled correctly as qasd_var_auth_t as the fcontext states? Is the
> software installer supposed to force a relabel on a post-install?
>
> After a restart of the daemon I do not see the pid file being labelled
> correctly:
>
> # /etc/init.d/vasd restart Stopping vasd: vasd does not appear to be
> running. Starting vasd: [ OK
> ]
>
> # ls -laZ /var/opt/quest/vas/vasd/ drwxr-xr-x. daemon daemon
> unconfined_u:object_r:vasd_var_t:s0 . drwxr-xr-x. root root
> unconfined_u:object_r:vasd_var_t:s0 .. srwxrwxrwx. daemon daemon
> unconfined_u:object_r:vasd_var_t:s0 .vasd_19574 srwxrwxrwx. daemon daemon
> unconfined_u:object_r:vasd_var_t:s0 .vasd_19575 srwxrwxrwx. daemon daemon
> unconfined_u:object_r:vasd_var_t:s0 .vasd_19576 srwxrwxrwx. daemon daemon
> unconfined_u:object_r:vasd_var_t:s0 .vasd40_ipc_sock -rw-r--r--. daemon
> daemon unconfined_u:object_r:vasd_var_t:s0 .vasd.pid -rw-r--r--. daemon
> daemon unconfined_u:object_r:vasd_var_t:s0 vas_ident.vdb -rw-r--r--.
> daemon daemon unconfined_u:object_r:vasd_var_t:s0 vas_misc.vdb
>
> After forcing a relabel:
>
> # restorecon -F -R /var/opt/quest/vas/vasd/
>
> # ls -laZ /var/opt/quest/vas/vasd/ drwxr-xr-x. daemon daemon
> system_u:object_r:vasd_var_auth_t:s0 . drwxr-xr-x. root root
> unconfined_u:object_r:vasd_var_t:s0 .. srwxrwxrwx. daemon daemon
> system_u:object_r:vasd_var_auth_t:s0 .vasd_19574 srwxrwxrwx. daemon daemon
> system_u:object_r:vasd_var_auth_t:s0 .vasd_19575 srwxrwxrwx. daemon daemon
> system_u:object_r:vasd_var_auth_t:s0 .vasd_19576 srwxrwxrwx. daemon daemon
> system_u:object_r:vasd_var_auth_t:s0 .vasd40_ipc_sock -rw-r--r--. daemon
> daemon system_u:object_r:vasd_var_auth_t:s0 .vasd.pid -rw-r--r--. daemon
> daemon system_u:object_r:vasd_var_auth_t:s0 vas_ident.vdb -rw-r--r--.
> daemon daemon system_u:object_r:vasd_var_auth_t:s0 vas_misc.vdb
>
> I get the files and directory labelled correctly, but not the pid file. I
> can set a pid transition in the policy but then what is the point of
> setting a file context in the <domain>.fc for the pid file if it never
> gets picked up? Apparently I am missing something important here.
>
> Does anyone know a place for good documentation on this subject?
>
>
>
>
>
>
>
> -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
If RPM puts the files on disk and then installs your policy in post install,
it will not fix the labels.
You could create an vasd-selinux.rpm and require this to be installed before
the vasd.rpm is installed. In that case the rpm should do the right thing, at
least on Fedora/RHEL7. Not sure about RHEL6.
Otherwise you can just run restorecon in the post install.
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux