If the context for /var/opt/quest/vas/vasd(/.*)? all files system_u:object_r:vasd_var_auth_t:s0
Is already in place before the product is installed via rpm, should rpm correctly label the dir/files as they are laid down?
Sent from my Windows Phone
Is already in place before the product is installed via rpm, should rpm correctly label the dir/files as they are laid down?
Sent from my Windows Phone
From: Daniel J Walsh
Sent: 2/14/2014 6:52 AM
To: Jayson Hurst; selinux@xxxxxxxxxxxxxxxxxxxxxxx
Subject: Re: How to properly setup my domains security contexts in the domain.fc file?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/14/2014 01:23 AM, Jayson Hurst wrote:
> The policy was in play before installing the product, also why doesn't the
> pid file get labeled correctly?
Pid files are created by the app, and the app does not look at the file
context. file_context is just there to tell SELinux aware apps how to label
content. (restorecon,rpm) If non SELinux aware apps create content then you
need file transition rules.
>
> Sent from my Windows Phone
> --------------------------------------------------------------------------------
>
>
From: Daniel J Walsh <mailto:dwalsh@xxxxxxxxxx>
> Sent: 2/13/2014 6:58 PM To: Jayson Hurst <mailto:swazup@xxxxxxxxxxx>;
> selinux@xxxxxxxxxxxxxxxxxxxxxxx <mailto: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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlL+H6YACgkQrlYvE4MpobOO0QCdGcCRlnqq7Awd6NhbBUBUVAXQ
2cEAnjuKTxPbeMJb6WJRtXPwgwUJRMIc
=IrPG
-----END PGP SIGNATURE-----
Hash: SHA1
On 02/14/2014 01:23 AM, Jayson Hurst wrote:
> The policy was in play before installing the product, also why doesn't the
> pid file get labeled correctly?
Pid files are created by the app, and the app does not look at the file
context. file_context is just there to tell SELinux aware apps how to label
content. (restorecon,rpm) If non SELinux aware apps create content then you
need file transition rules.
>
> Sent from my Windows Phone
> --------------------------------------------------------------------------------
>
>
From: Daniel J Walsh <mailto:dwalsh@xxxxxxxxxx>
> Sent: 2/13/2014 6:58 PM To: Jayson Hurst <mailto:swazup@xxxxxxxxxxx>;
> selinux@xxxxxxxxxxxxxxxxxxxxxxx <mailto: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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlL+H6YACgkQrlYvE4MpobOO0QCdGcCRlnqq7Awd6NhbBUBUVAXQ
2cEAnjuKTxPbeMJb6WJRtXPwgwUJRMIc
=IrPG
-----END PGP SIGNATURE-----
-- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
