VASD policy

[Vadym Chepkov]

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

[Daniel J Walsh]

-----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 [e-mail] 
> https://admin.fedoraproject.org/mailman/listinfo/selinux

What kind of problems are you having with it?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlHtdyoACgkQrlYvE4MpobN2RwCeIGDqg5W+zMPUk6CWtrmSFUi1
> +SUAn1QLOGMR5mLtL0Z+ri93eJIXvx6Q
> =t4dK
> -----END PGP SIGNATURE-----

[Vadym Chepkov]

On Mon, Jul 22, 2013 at 2:17 PM, Daniel J Walsh  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

[Tony Scully]

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  wrote:
> On Mon, Jul 22, 2013 at 2:17 PM, Daniel J Walsh  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
> [e-mail]
> https://admin.fedoraproject.org/mailman/listinfo/selinux

[Daniel J Walsh]

-----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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.13 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlHu1aEACgkQrlYvE4MpobOs+ACgvyOqx89Obd+oT99OCNyY1Tud
> ddYAoLvXS/ZYjwfIyivEdtVbVm+LFt+v
> =oN5b
> -----END PGP SIGNATURE-----

[Vadym Chepkov]

On Jul 23, 2013, at 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;
>
> 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