RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1294663 - assigning or removing selinux roles produces two audit events
Summary: assigning or removing selinux roles produces two audit events
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: policycoreutils
Version: 7.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Vit Mojzis
QA Contact: Jan Zarsky
URL:
Whiteboard:
Depends On: 1622045
Blocks: 1624764
TreeView+ depends on / blocked
 
Reported: 2015-12-29 14:20 UTC by Ondrej Moriš
Modified: 2018-10-30 09:47 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1624764 (view as bug list)
Environment:
Last Closed: 2018-10-30 09:46:22 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3098 0 None None None 2018-10-30 09:47:11 UTC

Description Ondrej Moriš 2015-12-29 14:20:06 UTC 
Description of problem:

Suppose I want to add a selinux role for a user:

# semanage login -a -s staff_u user23875

According to user account lifecycle auditing specification [1], I would expect a single ROLE_ASSIGN audit event generated by semanage with message containing user name, old role and new role. Instead I got two messages:

# ausearch -ts recent -m ROLE_ASSIGN
----
type=ROLE_ASSIGN msg=audit(1451384622.798:441): pid=3345 uid=0 auid=0 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=login-sename,role,range acct="user23875" old-seuser=? old-role=? old-range=? new-seuser=staff_u new-role=staff_r,sysadm_r,system_r,unconfined_r new-range=s0-s0:c0.c1023 exe="/usr/bin/python2.7" hostname=? addr=? terminal=pts/0 res=success'
----
type=ROLE_ASSIGN msg=audit(1451384624.267:443): pid=3345 uid=0 auid=0 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=login-sename,role acct="user23875" old-seuser=unconfined_u old-role=system_r,unconfined_r old-range=s0-s0:c0.c1023 new-seuser=staff_u new-role=staff_r,sysadm_r,system_r,unconfined_r new-range=s0-s0:c0.c1023 exe=/usr/sbin/semanage hostname=? addr=? terminal=pts/0 res=success'

I see two issues here:

  1. What is the point of the first event generated by python2.7?
  2. Shouldn't "op" in second message be "login-sename,role,range"?
 
Well, regardless of unexpected "exe" one might say that the first event is caused by setting default role unconfined_r for the user who has no assigned role before. Hence changing already assigned role from one to another should really produce just a single event, right?

# semanage login -a -s system_u user23875

But...

# ausearch -ts recent -m ROLE_ASSIGN
----
time->Tue Dec 29 09:04:52 2015
type=ROLE_ASSIGN msg=audit(1451397892.094:1161): pid=11870 uid=0 auid=0 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=login-sename,role acct="user23875" old-seuser=staff_u old-role=staff_r,sysadm_r,system_r,unconfined_r old-range=s0-s0:c0.c1023 new-seuser=system_u new-role=system_r,unconfined_r new-range=s0-s0:c0.c1023 exe="/usr/bin/python2.7" hostname=? addr=? terminal=pts/0 res=success'
----
time->Tue Dec 29 09:04:53 2015
type=ROLE_ASSIGN msg=audit(1451397893.762:1163): pid=11870 uid=0 auid=0 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=login-sename,role acct="user23875" old-seuser=staff_u old-role=staff_r,sysadm_r,system_r,unconfined_r old-range=s0-s0:c0.c1023 new-seuser=? new-role=system_r,unconfined_r new-range=s0-s0:c0.c1023 exe=/usr/sbin/semanage hostname=? addr=? terminal=pts/0 res=success'

So the role is re-set to default one and then changed to a desired one, again first event is produced by python2.7 rather than semanage and "op" is different again.

Would it be possible to "merge" twe two event to a single one? If that's is not desired or possible, please feel free to close the bug but in that case explain your reasoning please.

[1] https://people.redhat.com/sgrubb/audit/user-account-lifecycle.txt

Version-Release number of selected component (if applicable):

policycoreutils-2.2.5-20.el7

How reproducible:

100%

Steps to Reproduce:

See above.

Actual results:

Two different audit event per semanage login update.

Expected results:

One audit event per semanage login update.

Additional info:

The same apply for ROLE_REMOVE event.
Comment 1 Ondrej Moriš 2015-12-30 10:54:12 UTC 
FYI: On RHEL6, there is just one audit event for ROLE_ASSIGN and one for ROLE_REMOVE:

----
type=ROLE_ASSIGN msg=audit(1451472676.152:1088): user pid=27734 uid=0 auid=0 ses=131 subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 msg='op=login-sename,role acct="user29483" old-seuser=unconfined_u old-role=system_r,unconfined_r old-range=s0-s0:c0.c1023 new-seuser=staff_u new-role=staff_r,sysadm_r,system_r,unconfined_r new-range=s0-s0:c0.c1023 exe=/usr/sbin/semanage hostname=? addr=? terminal=pts/0 res=success'
----
type=ROLE_REMOVE msg=audit(1451472685.511:1090): user pid=27773 uid=0 auid=0 ses=131 subj=unconfined_u:unconfined_r:semanage_t:s0-s0:c0.c1023 msg='op=login acct="user29483" old-seuser=staff_u old-role=staff_r,sysadm_r,system_r,unconfined_r old-range=s0-s0:c0.c1023 new-seuser=unconfined_u new-role=system_r,unconfined_r new-range=s0-s0:c0.c1023 exe=/usr/sbin/semanage hostname=? addr=? terminal=pts/0 res=success'
Comment 3 Vit Mojzis 2018-06-13 16:40:37 UTC 
Thank you for reporting the issue.

Ad 1.
The first message is actually reported by libsemanage code and is more accurate.
The second one is reported by semanage code. getseuserbyname returns values for __default__ selinux user when given non existing user (without any indication). That is why the second message contains old-seuser even though there was none.
I'll discuss removing the audit message generated by semanage with upstream.

Ad 2.
Yes, it should, but semanage doesn't know that the range changed (getseuserbyname fooled it with __default__ seuser values).
Comment 4 Vit Mojzis 2018-06-19 10:06:57 UTC 
https://marc.info/?l=selinux&m=152938766509520&w=4
Comment 11 errata-xmlrpc 2018-10-30 09:46:22 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3098
Note You need to log in before you can comment on or make changes to this bug.