-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/19/2010 10:33 AM, Daniel J Walsh wrote:
> The reason for this is threshold, setting. I think the interfaces are
> getting more complicated and one AVC that is looking for read ends up
> being two far different from the threshold, so audit2allow does not
> report it.
>
> For example.
>
> node=(removed) type=AVC msg=audit(1271587735.632:422): avc: denied {
> getattr } for pid=13239 comm="openvpn"
> path="/home/bbaetz/.pki/vpn01_cacert.pem" dev=dm-3 ino=565334
> scontext=system_u:system_r:openvpn_t:s0
> tcontext=unconfined_u:object_r:home_cert_t:s0 tclass=file
>
> node=(removed) type=SYSCALL msg=audit(1271587735.632:422): arch=c000003e
> syscall=5 success=yes exit=0 a0=6 a1=7fffd84f4a20 a2=7fffd84f4a20 a3=18
> items=0 ppid=13235 pid=13239 auid=4294967295 uid=0 gid=0 euid=0 suid=0
> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="openvpn"
> exe="/usr/sbin/openvpn" subj=system_u:system_r:openvpn_t:s0 key=(null)
>
> Finds userdom_read_home_certs but it's threshold is two far off, so it
> reports nothing.
>
> I think we should either eliminate the threshold and report the best
> interface that we have, and let the policy writer decide if he wants the
> match.
>
> If you look at the interface userdom_read_home_certs.
>
> [InterfaceVector userdom_read_home_certs $1:source ]
> $1,home_cert_t,file,read,lock,getattr,open,ioctl
> $1,home_cert_t,dir,ioctl,search,read,lock,open,getattr
> $1,home_cert_t,lnk_file,read,getattr
> $1,home_root_t,dir,getattr,open,search
> $1,home_root_t,lnk_file,read,getattr
> $1,user_home_dir_t,dir,getattr,open,search
> $1,user_home_dir_t,lnk_file,read,getattr
>
> A domain that is allowed to search the homedir is always going to
> generate an AVC that is a long way off.
>
> I thing we should either remove the bastards and just add all as childs,
> or recode it like the attachment.
>
I tried that but we got down to,
# userdom_read_home_certs(openvpn_t) # [283]
Which is still way higher then 120.
Isn't the problem that openvpn_t has
1# sesearch -A -s openvpn_t -t home_root_t
Found 2 semantic av rules:
allow openvpn_t home_root_t : dir { getattr search open } ;
allow openvpn_t home_root_t : lnk_file { read getattr } ;
- -bash-4.1# sesearch -A -s openvpn_t -t user_home_dir_t
Found 1 semantic av rules:
allow openvpn_t user_home_dir_t : dir { ioctl read getattr lock
search open } ;
But these count towards the total?
Should we be checking in the policy what access is already present in
the domain, to make a better decision. Or would this end up taking to long.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkvNvkYACgkQrlYvE4MpobPVGQCfZEeAd1f7424uWXrJGbiUDyPZ
Z5UAn1k60lKjKJxZtq5d6ON51iKMvda2
=2SYZ
-----END PGP SIGNATURE-----
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
