Hide Forgot
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.
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'
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).
https://marc.info/?l=selinux&m=152938766509520&w=4
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