-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/26/2010 01:55 PM, Thomson, David-P63356 wrote:
> It was not a conditional allow rule and I personally retrieved the
> policy file and examined it.
>
>
> Turned out it was a constraint that had been put in before either of us
> had touched the policy:
>
> constrain tcp_socket { send_msg recv_msg }
> (
> t2 != ssh_port_t
> ...
> );
>
>
> In the future I'll remember to check the constraints before I ping you
> guys. Having a compile time error would have been nice (like for
> neverallows) or if at runtime there was some history of if the "0" in
> the AV permission mask was due to no allow rule being added, or due to a
> constraint clearing the bit. That could then have been reflected in the
> audit message. The first option sounds easier.
>
> In the end, this can just be chalked up to "user error" for not checking
> for the policy canceling itself out, but something to help in debugging
> would be nice if it weren't too much of a hassle. We are working with
> such old policy that maybe you have addressed this already in the newer
> SELinux stuff you churn out.
>
> Thanks again!
>
>
>
> -----Original Message-----
> From: Stephen Smalley [mailto:sds@xxxxxxxxxxxxx]
> Sent: Monday, April 26, 2010 6:07 AM
> To: Thomson, David-P63356
> Cc: SELinux@xxxxxxxxxxxxx
> Subject: Re: denial even with appropriate allow rules
>
> On Fri, 2010-04-23 at 14:49 -0700, Thomson, David-P63356 wrote:
>> I'm helping a co-worker with a policy problem. In permissive he gets
> a
>> couple denials:
>>
>> type=AVC msg=audit(1272049866.598:32539): avc: denied { send_msg }
> for
>> saddr=192.168.99.128 src=32786 daddr=192.168.99.1 dest=22 netif=eth0
>> scontext=system_u:system_r:sshd_t
> tcontext=system_u:object_r:ssh_port_t
>> tclass=tcp_socket
>>
>> type=AVC msg=audit(1272049866.598:32540): avc: denied { recv_msg }
> for
>> saddr=192.168.99.1 src=22 daddr=192.168.99.128 dest=32786 netif=eth0
>> scontext=system_u:system_r:sshd_t
> tcontext=system_u:object_r:ssh_port_t
>> tclass=tcp_socket
>>
>> I've checked his source policy and even checked the policy.18 file on
>> his target machine, they both show:
>>
>> Allow sshd_t ssh_port_t : tcp_socket { recv_msg send_msg ... };
>>
>> The only time I've seen it ignore networking policy was when I was
> doing
>> it the old (pre-secmark) way but forgot to put selinux_compat_net=1 on
>> the kernel line. His kernel version is 2.6.9 so this should predate
>> secmark and need no flag, correct? There is no /selinux/compat_net
> file
>> on the machine so I assume it should just work.
>>
>> This is a fairly old and well "customized" policy, if that matters.
>>
>>
>> Any ideas?
>
> Is the allow rule conditional (within an if statement) or unconditional?
>
> Are you sure the policy file you are examining is the one that was
> loaded into the kernel?
>
The latest audit2allow in Fedora is automatically checking with the
policy to see why the AVC was generated.
So it would have said something like constraint violation.
You can also use audit2allow -w (audit2why) to ask the system why the
AVC is happening.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkvW3WQACgkQrlYvE4MpobP3LQCgpBftuwZv95yvbtQdC//P1JkN
9s8Ani0eSEl5qDW6LoyuBMqMFn04kmYY
=kLeY
-----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.
