RHEL auth_role using logging_send_audit_msgs

RHEL auth_role using logging_send_audit_msgs

[Ted Toth]

The RHEL version of the auth_role macro which we are getting through
our use of userdom_unpriv_user_template uses logging_send_audit_msgs
which give a type the audit_write capability and allow rules for a
number of netlink_audit_socket operations. It seem counterintuitive to
give an unprivileged user type audit write related policy.The
ref-policy version of auth_role does not use logging_send_audit_msgs.
We're considering patching our policy but I wanted to see what others
though about giving unprivileged user types this policy?

Ted

Re: RHEL auth_role using logging_send_audit_msgs

[Dominick Grift]

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

On Tue, Feb 26, 2019 at 04:20:42PM -0600, Ted Toth wrote:
> The RHEL version of the auth_role macro which we are getting through
> our use of userdom_unpriv_user_template uses logging_send_audit_msgs
> which give a type the audit_write capability and allow rules for a
> number of netlink_audit_socket operations. It seem counterintuitive to
> give an unprivileged user type audit write related policy.The
> ref-policy version of auth_role does not use logging_send_audit_msgs.
> We're considering patching our policy but I wanted to see what others
> though about giving unprivileged user types this policy?
> 
> Ted

I think this should indeed probably be dontaudited (i have a few of those in my policy as well, so do as i say not as i do)

Might have been added because of some unpriviliged user space object manager trying to log to audit. These would not have been allowed anyway.

XSELinux, old dbus come to mind.

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: RHEL auth_role using logging_send_audit_msgs

[Dominick Grift]

On Wed, Feb 27, 2019 at 09:21:07AM +0100, Dominick Grift wrote:
> On Tue, Feb 26, 2019 at 04:20:42PM -0600, Ted Toth wrote:
> > The RHEL version of the auth_role macro which we are getting through
> > our use of userdom_unpriv_user_template uses logging_send_audit_msgs
> > which give a type the audit_write capability and allow rules for a
> > number of netlink_audit_socket operations. It seem counterintuitive to
> > give an unprivileged user type audit write related policy.The
> > ref-policy version of auth_role does not use logging_send_audit_msgs.
> > We're considering patching our policy but I wanted to see what others
> > though about giving unprivileged user types this policy?
> > 
> > Ted
> 
> I think this should indeed probably be dontaudited (i have a few of those in my policy as well, so do as i say not as i do)
> 
> Might have been added because of some unpriviliged user space object manager trying to log to audit. These would not have been allowed anyway.
> 
> XSELinux, old dbus come to mind.

Actually, I don't think its this simple. There are also setuid pam clients like for example screen.

I do think the goal should at least be to not allow this to user shells, by moving any pam clients out of the shell domain and into private domains.

Looking at my policy i think i settled for that compromize. I moved all known pam clients and user space object managers to private domains.
But i also rely a little on DAC here. Atleast access is contained to just these domains.

Take for example xserver it can be run as root and as unpriv user. xserver is both pam client as well as user space object manager. So unless you want to overcomplicate things you end up giving xserver pam access/audit access whether it runs as root or not

> 
> -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift



-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

Re: RHEL auth_role using logging_send_audit_msgs

[Stephen Smalley]

On 2/26/19 5:20 PM, Ted Toth wrote:
> The RHEL version of the auth_role macro which we are getting through
> our use of userdom_unpriv_user_template uses logging_send_audit_msgs
> which give a type the audit_write capability and allow rules for a
> number of netlink_audit_socket operations. It seem counterintuitive to
> give an unprivileged user type audit write related policy.The
> ref-policy version of auth_role does not use logging_send_audit_msgs.
> We're considering patching our policy but I wanted to see what others
> though about giving unprivileged user types this policy?

I agree that it doesn't seem like a good idea.  Should probably file a 
bugzilla for redhat.