Hi,
I noticed just one vasd related entry found it's way into SELinux policy:
# grep vasd ./serefpolicy-3.7.19/policy/modules/system/authlogin.fc /var/opt/quest/vas/vasd(/.*)? gen_context(system_u:object_r:var_auth_t,s0)
vasd is part of Quest Auth Services and I wonder if somebody already has a policy defined for it or I have to start from scratch. Quest suggested to disable SELinux, of cause.
Thanks, Vadym
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/22/2013 11:23 AM, Vadym Chepkov wrote:
Hi,
I noticed just one vasd related entry found it's way into SELinux policy:
# grep vasd ./serefpolicy-3.7.19/policy/modules/system/authlogin.fc /var/opt/quest/vas/vasd(/.*)? gen_context(system_u:object_r:var_auth_t,s0)
vasd is part of Quest Auth Services and I wonder if somebody already has a policy defined for it or I have to start from scratch. Quest suggested to disable SELinux, of cause.
Thanks, Vadym
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
What kind of problems are you having with it?
On Mon, Jul 22, 2013 at 2:17 PM, Daniel J Walsh dwalsh@redhat.com wrote:
What kind of problems are you having with it?
It doesn't work with SELinux in enforcing mode.
# ausearch -m avc -ts recent ---- time->Tue Jul 23 10:41:47 2013 type=SYSCALL msg=audit(1374590507.830:3207): arch=c000003e syscall=42 success=yes exit=0 a0=4 a1=7fff1e6b5530 a2=6e a3=7fff1e6b5280 items=0 ppid=1208 pid=29329 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1374590507.830:3207): avc: denied { connectto } for pid=29329 comm="sshd" path="/var/opt/quest/vas/vasd/.vasd40_ipc_sock" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket ---- time->Tue Jul 23 10:41:51 2013 type=SYSCALL msg=audit(1374590511.523:3217): arch=c000003e syscall=42 success=yes exit=0 a0=4 a1=7fff1e6b5530 a2=6e a3=2 items=0 ppid=1208 pid=29329 auid=40481 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=471 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1374590511.523:3217): avc: denied { connectto } for pid=29329 comm="sshd" path="/var/opt/quest/vas/vasd/.vasd40_ipc_sock" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket ---- time->Tue Jul 23 10:41:51 2013 type=SYSCALL msg=audit(1374590511.400:3209): arch=c000003e syscall=2 success=yes exit=7 a0=7f085f9b3470 a1=241 a2=1b6 a3=0 items=0 ppid=1208 pid=29329 auid=4294967295 uid=0 gid=0 euid=40481 suid=0 fsuid=40481 egid=4105 sgid=0 fsgid=4105 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1374590511.400:3209): avc: denied { write } for pid=29329 comm="sshd" name=".vas_logon_server" dev=dm-3 ino=16 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
Hi Vadym,
In fact vasd just runs unconfined under selinux; the issue you have is that sshd is running in the sshd_t context, but need to access some files, the vasd cache (I think it's via PAM) in /var/opt/quest/vas.
Quest (now Dell) do provide a policy file which allows sshd to access these files, here's the text version:
module sshdqas 1.0;
require { type semanage_t; type var_t; type sshd_t; type initrc_t; class sock_file write; class unix_stream_socket connectto; class file { read write getattr open }; }
#============= semanage_t ============== allow semanage_t var_t:sock_file write;
#============= sshd_t ============== allow sshd_t initrc_t:unix_stream_socket connectto; allow sshd_t var_t:file open; allow sshd_t var_t:file { read write getattr }; allow sshd_t var_t:sock_file write;
Which as you can see, just allows sshd to access var_t labelled files -- might be considered too permssive?
But vasd itself should run ( and is 'supported') unconfined under selinux.
Cheers, Tony I
On Tue, Jul 23, 2013 at 3:43 PM, Vadym Chepkov vchepkov@gmail.com wrote:
On Mon, Jul 22, 2013 at 2:17 PM, Daniel J Walsh dwalsh@redhat.com wrote:
What kind of problems are you having with it?
It doesn't work with SELinux in enforcing mode.
# ausearch -m avc -ts recent
time->Tue Jul 23 10:41:47 2013 type=SYSCALL msg=audit(1374590507.830:3207): arch=c000003e syscall=42 success=yes exit=0 a0=4 a1=7fff1e6b5530 a2=6e a3=7fff1e6b5280 items=0 ppid=1208 pid=29329 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1374590507.830:3207): avc: denied { connectto } for pid=29329 comm="sshd" path="/var/opt/quest/vas/vasd/.vasd40_ipc_sock" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
time->Tue Jul 23 10:41:51 2013 type=SYSCALL msg=audit(1374590511.523:3217): arch=c000003e syscall=42 success=yes exit=0 a0=4 a1=7fff1e6b5530 a2=6e a3=2 items=0 ppid=1208 pid=29329 auid=40481 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=471 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1374590511.523:3217): avc: denied { connectto } for pid=29329 comm="sshd" path="/var/opt/quest/vas/vasd/.vasd40_ipc_sock" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=unix_stream_socket
time->Tue Jul 23 10:41:51 2013 type=SYSCALL msg=audit(1374590511.400:3209): arch=c000003e syscall=2 success=yes exit=7 a0=7f085f9b3470 a1=241 a2=1b6 a3=0 items=0 ppid=1208 pid=29329 auid=4294967295 uid=0 gid=0 euid=40481 suid=0 fsuid=40481 egid=4105 sgid=0 fsgid=4105 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1374590511.400:3209): avc: denied { write } for pid=29329 comm="sshd" name=".vas_logon_server" dev=dm-3 ino=16 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/23/2013 11:14 AM, Tony Scully wrote:
Hi Vadym,
In fact vasd just runs unconfined under selinux; the issue you have is that sshd is running in the sshd_t context, but need to access some files, the vasd cache (I think it's via PAM) in /var/opt/quest/vas.
Quest (now Dell) do provide a policy file which allows sshd to access these files, here's the text version:
module sshdqas 1.0;
require { type semanage_t; type var_t; type sshd_t; type initrc_t; class sock_file write; class unix_stream_socket connectto; class file { read write getattr open }; }
#============= semanage_t ============== allow semanage_t var_t:sock_file write;
#============= sshd_t ============== allow sshd_t initrc_t:unix_stream_socket connectto; allow sshd_t var_t:file open; allow sshd_t var_t:file { read write getattr }; allow sshd_t var_t:sock_file write;
Well in Fedora these should be labeled var_auth_t.
restorecon -R -v /var/opt
On Jul 23, 2013, at 11:14 AM, Tony Scully tonyjscully@gmail.com wrote:
Hi Vadym,
In fact vasd just runs unconfined under selinux; the issue you have is that sshd is running in the sshd_t context, but need to access some files, the vasd cache (I think it's via PAM) in /var/opt/quest/vas.
Quest (now Dell) do provide a policy file which allows sshd to access these files, here's the text version:
module sshdqas 1.0;
require { type semanage_t; type var_t; type sshd_t; type initrc_t; class sock_file write; class unix_stream_socket connectto; class file { read write getattr open }; }
#============= semanage_t ============== allow semanage_t var_t:sock_file write;
#============= sshd_t ============== allow sshd_t initrc_t:unix_stream_socket connectto; allow sshd_t var_t:file open; allow sshd_t var_t:file { read write getattr }; allow sshd_t var_t:sock_file write;
Which as you can see, just allows sshd to access var_t labelled files -- might be considered too permssive?
But vasd itself should run ( and is 'supported') unconfined under selinux.
It looks like a workaround to me, not a proper policy, but at least I don’t have do disable SELinux. I ended up with this:
module qas 1.0;
require { type var_auth_t; type sshd_t; type system_dbusd_t; type initrc_t; class sock_file write; class unix_stream_socket connectto; class file { read write getattr open }; }
allow sshd_t initrc_t:unix_stream_socket connectto; allow sshd_t var_auth_t:file { open read write getattr }; allow sshd_t var_auth_t:sock_file write;
allow system_dbusd_t initrc_t:unix_stream_socket connectto; allow system_dbusd_t var_auth_t:file { open read write getattr }; allow system_dbusd_t var_auth_t:sock_file write;
Thanks, Vadym
selinux@lists.fedoraproject.org
-
Daniel J Walsh -
Tony Scully -
Vadym Chepkov