Allow audit2allow to return constraint information from policy

Allow audit2allow to return constraint information from policy

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 1274 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

At the end of last year I was complaining about audit2allow and the SELinux
tools chain not being able to give better information about what constraint is
being violated, so a admin or policy writer could have a clue on how to fix
the problem.

A fairly common problem is domains trying to change the role or user component
of the label.  Or in the MCS and MLS world, what attribute do I need to add to
my policy to allow the AVC.

Richard Haines wrote some nice patches to add the constraint information to
the kernel and to change user space to reveal this information.

Sadly we thought these discussions had happened on the list, but I guess we
had taken it private.  Here is the userspace patch to reveal this information.

The kernel team will be posting the kernel patch hopefully soon.  We believe
that even though the kernel does not need the additional information about the
constraint, the limited space required to carry this information makes sense.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJpIHwACgkQrlYvE4MpobM6vgCg3IoQr5tlM8NVgT/pId2QpKrz
E5gAoInxyCNAOQuXA1M6Z1YX36U9y31u
=3Ern
-----END PGP SIGNATURE-----

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Richard-Haines-patch-that-allows-us-discover-constra.patch --]
[-- Type: text/x-patch; name="0001-Richard-Haines-patch-that-allows-us-discover-constra.patch", Size: 0 bytes --]

Re: Allow audit2allow to return constraint information from policy

[Dominick Grift]

On Thu, 2013-10-24 at 09:28 -0400, Daniel J Walsh wrote:
> At the end of last year I was complaining about audit2allow and the SELinux
> tools chain not being able to give better information about what constraint is
> being violated, so a admin or policy writer could have a clue on how to fix
> the problem.
> 
> A fairly common problem is domains trying to change the role or user component
> of the label.  Or in the MCS and MLS world, what attribute do I need to add to
> my policy to allow the AVC.
> 
> Richard Haines wrote some nice patches to add the constraint information to
> the kernel and to change user space to reveal this information.
> 
> Sadly we thought these discussions had happened on the list, but I guess we
> had taken it private.  Here is the userspace patch to reveal this information.
> 
> The kernel team will be posting the kernel patch hopefully soon.  We believe
> that even though the kernel does not need the additional information about the
> constraint, the limited space required to carry this information makes sense.
> 


Can we though make that information opt-in

I think it annoying that when i run audit2allow my screen gets filled
with all kinds of information i am not interested in

I could find a option to get rid of the noise


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Allow audit2allow to return constraint information from policy

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/24/2013 12:02 PM, Dominick Grift wrote:
> On Thu, 2013-10-24 at 09:28 -0400, Daniel J Walsh wrote:
>> At the end of last year I was complaining about audit2allow and the
>> SELinux tools chain not being able to give better information about what
>> constraint is being violated, so a admin or policy writer could have a
>> clue on how to fix the problem.
>> 
>> A fairly common problem is domains trying to change the role or user
>> component of the label.  Or in the MCS and MLS world, what attribute do I
>> need to add to my policy to allow the AVC.
>> 
>> Richard Haines wrote some nice patches to add the constraint information
>> to the kernel and to change user space to reveal this information.
>> 
>> Sadly we thought these discussions had happened on the list, but I guess
>> we had taken it private.  Here is the userspace patch to reveal this
>> information.
>> 
>> The kernel team will be posting the kernel patch hopefully soon.  We
>> believe that even though the kernel does not need the additional
>> information about the constraint, the limited space required to carry
>> this information makes sense.
>> 
> 
> 
> Can we though make that information opt-in
> 
> I think it annoying that when i run audit2allow my screen gets filled with
> all kinds of information i am not interested in
> 
> I could find a option to get rid of the noise
> 
> 
> -- This message was distributed to subscribers of the selinux mailing
> list. If you no longer wish to subscribe, send mail to
> majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes
> as the message.
> 
Well I think it should be opt out.

You could easily make a script to do this, something like:

audit2allow $@ | grep ^allow

But it is something I would like to add.

audit2allow -q

Or something like that.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlJpTYsACgkQrlYvE4MpobOnwACfeTrGTGApAl16dUInFwydpa7M
qfYAniJOtt5Yq2hAHgCMgOKH+MriOwj7
=g/bx
-----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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: Allow audit2allow to return constraint information from policy

[Stephen Smalley]

On 10/24/2013 09:28 AM, Daniel J Walsh wrote:
> Sadly we thought these discussions had happened on the list, but I guess we
> had taken it private.  Here is the userspace patch to reveal this information.
> 
> The kernel team will be posting the kernel patch hopefully soon.  We believe
> that even though the kernel does not need the additional information about the
> constraint, the limited space required to carry this information makes sense.

I gave comments on the kernel patch, so hopefully that can be revised
and resubmitted.

For this one, can we get the patch submitted by Richard after making
changes as per these comments?

And I think it should be split up into separate patches for libsepol,
libselinux, policycoreutils, and sepolgen.

Check your coding style as per CodingStyle, use scripts/checkpatch.pl
from the kernel as a rough guide, and use scripts/Lindent as a last
resort if you've messed up.

Why did we need a new modular format version in addition to a new kernel
format version?  You don't appear to use it anywhere.

On the sepol_class_name_to_id() and sepol_perm_name_to_av() helpers,
libselinux has security_class_to_string() / string_to_security_class()
and security_av_perm_to_string() / string_to_av_perm() /
security_av_string() helpers and libsepol has sepol_av_to_string().
Just wondering if we should try and use consistent names aside from
sepol_ prefix and different implementations (policy-based vs
selinuxfs-based).

Output looks like:
# audit2why -p /etc/selinux/targeted/policy/policy.29 < avc
type=AVC msg=audit(1382706778.165:3267): avc:  denied  { signal } for
pid=4076 comm="bash"
scontext=unconfined_u:unconfined_r:sandbox_t:s0:c353,c935
tcontext=unconfined_u:unconfined_r:sandbox_t:s0:c96,c826 tclass=process

	Was caused by:

#Constraint rule:
	mlsconstrain process { signal } ((h1 dom h2 -Fail-)  or (t1=sandbox_t
neq TYPE_ENTRY -Fail-) { POLICY_SOURCE: mcs_constrained_type } );
Constraint DENIED
mlsconstrain process { sigkill sigstop } ((h1 dom h2 -Fail-)  or
(t1=sandbox_t  neq TYPE_ENTRY -Fail-) { POLICY_SOURCE:
mcs_constrained_type } ); Constraint DENIED

#	Possible cause is the source level (s0:c353,c935) and target level
(s0:c96,c826) are different.

Is there a reason it wasn't displayed in the same way as the original
constraint (e.g. why doesn't it say ( t1 != mcs_constrained_type), why
is it partially postfix notation (neq) and what is the purpose of
putting TYPE_ENTRY into the output?  And why didn't it suggest assigning
the attribute to the source type as an alternative fix?

Buffer/string management looks...complicated.  Can we reduce all of the
copying/allocation that goes on there?  And have you run this through
valgrind (likely need a C test program that directly uses the libsepol
interface; could even add it as a menu option under the debug (-d)
facility of checkpolicy).

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.