RFE: Support for setting seuser in selinux_fcontexts

[benblasco]

I see a comment in https://github.com/linux-system-roles/selinux/blob/master/tasks/main.yml suggesting that seuser and selevel handling functionality need to be added to this role:

    # FIXME: selevel, seuser

The community sefcontext module handles this by not touching the seuser if none is defined:
https://github.com/ansible-collections/community.general/blob/main/plugins/modules/system/sefcontext.py

     if seuser is None:
                seuser = orig_seuser

Is it straightforward enough to add a conditional to this role to not attempt to pass seuser (or selevel) to the sefcontext if the value is not defined? I would be happy to contribute a PR for this functionality if this is what we envisage that the role needs.

[richm]

Will this fix the issue?

- name: Set SELinux file contexts
  sefcontext:
    target: "{{ item.target }}"
    setype: "{{ item.setype }}"
    ftype: "{{ item.ftype | default('a') }}"
    state: "{{ item.state | default('present') }}"
    selevel: "{{ item.selevel | default(omit) }}"
    seuser: "{{ item.seuser | default(omit) }}"
  with_items: "{{ selinux_fcontexts }}"

That is - if selevel is not present in item, do not pass it to the sefcontext module.

[benblasco]

Yes, "omit" was what I had been looking at.

I can fork, test, and PR if you like!

[richm]

Yes, "omit" was what I had been looking at.

I can fork, test, and PR if you like!

Sure - thanks - much appreciated!

[benblasco]

According to this document:
"On a targeted system, all users are mapped to the unconfined_u SELinux user. "

https://wiki.gentoo.org/wiki/SELinux/Users_and_logins

If that is the case on Enterprise Linux systems, then there is no need for this RFE. I am exploring further and will advise once I know more.

[bachradsusi]

When a file is created by a process it inherits user part from the process domain:

[staff@P1 ~]$ id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023
[staff@P1 ~]$ touch file
[staff@P1 ~]$ ls -Z file
staff_u:object_r:user_home_t:s0 file

If there's a file contexts matching a file, the user part is reset on restorecon or during relabel:

[root@P1 ~]# touch /etc/remove_me
[root@P1 ~]# ls -Z /etc/remove_me
unconfined_u:object_r:etc_t:s0 /etc/remove_me
[root@P1 ~]# matchpathcon /etc/remove_me 
/etc/remove_me  system_u:object_r:etc_t:s0
[root@P1 ~]# restorecon -Fv /etc/remove_me 
Relabeled /etc/remove_me from unconfined_u:object_r:etc_t:s0 to system_u:object_r:etc_t:s0

In general files contexts define system_u user for files:

# ls -Z /etc/passwd
system_u:object_r:passwd_file_t:s0 /etc/passwd

# semanage fcontext -l | grep /etc/passwd      
/etc/passwd[-\+]?                                  regular file       system_u:object_r:passwd_file_t:s0 

sefcontext.py uses system_u when seuser is not defined as well - https://github.com/ansible-collections/community.general/blob/main/plugins/modules/system/sefcontext.py#L195

And it's also important to say that in SELinux policies based on Fedora selinux-policy-targeted, the user part is not used when allow rules are evaluated:

[staff@P1 ~]$ id -Z
staff_u:staff_r:staff_t:s0-s0:c0.c1023
[staff@P1 ~]$ ls -Z unconfined_file 
unconfined_u:object_r:user_home_t:s0 unconfined_file
[staff@P1 ~]$ cat unconfined_file 
unconfined user data

So you would need a policy based on mls and also use it for files like those inside users home.

But given that how simple the patch would be, I would say lets add this to have a complete set of options available.

[richm]

any luck with this?

[benblasco]

PR submitted for review

#108

@bachradsusi @richm review welcome!

[benblasco]

@bachradsusi does it matter at all that this role performs a restorecon rather than a restorecon -F?

[bachradsusi]

Yes, it should use -F to force the reset of user part.

[benblasco]

@bachradsusi Should we be concerned about the implications of switching to -F more broadly?

[bachradsusi]

I don't think there's any negative implication of switching restorecon -F. targeted policy in Fedora based systems don't use the user and level part. But for Fedora mls policy it's important to reset the full context.