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 1710962 - Confined users are unable to get AFS tokens
Summary: Confined users are unable to get AFS tokens
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.1
Hardware: x86_64
OS: Linux
medium
low
Target Milestone: rc
: 8.2
Assignee: Lukas Vrabec
QA Contact: Milos Malik
URL:
Whiteboard:
Depends On:
Blocks: 1778780
TreeView+ depends on / blocked
 
Reported: 2019-05-16 16:12 UTC by Milos Malik
Modified: 2021-10-07 12:09 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1417671
Environment:
Last Closed: 2019-11-14 16:15:47 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-25189 0 None None None 2021-10-07 11:47:22 UTC

Description Milos Malik 2019-05-16 16:12:49 UTC
+++ This bug was initially created as a clone of Bug #1417671 +++

Description of problem:
We use the a 3rd party software called OpenAFS (http://www.openafs.org) to access home directories in AFS.  There already is policy added for support of using AFS (so everything is correctly labeled), however, I've discovered that the existing AFS policy needs to be updated to allow SELinux confined users to acquire AFS Tokens.

Version-Release number of selected component (if applicable):
selinux-policy-3.13.1-102.el7_3.13.noarch

How reproducible:
Always

Steps to Reproduce:
1. Install openafs software, I build my own repos here:
https://copr.fedorainfracloud.org/coprs/jsbillings/openafs/builds/
Note: this requires a working AFS cell and kerberos realm.
2. Set up a user that is confined and has an AFS account:
semanage login -a -s user_u myuser
3. Try to run 'aklog' as myuser

Actual results:
$ aklog
aklog: can't get afs configuration (afsconf_Open(/etc/openafs))

Expected results:
'aklog' should get AFS tokens from my kerberos tickets.

Additional info:

Here are the Audit logs for when I run aklog (permissive with dontaudit off):

type=AVC msg=audit(1485791285.432:1496): avc:  denied  { open } for  pid=3747 comm="aklog" path="/etc/openafs/ThisCell" dev="dm-0" ino=3408589 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:afs_config_t:s0 tclass=file
type=AVC msg=audit(1485791285.432:1496): avc:  denied  { read } for  pid=3747 comm="aklog" name="ThisCell" dev="dm-0" ino=3408589 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:afs_config_t:s0 tclass=file

type=AVC msg=audit(1485791285.438:1498): avc:  denied  { open } for  pid=3747 comm="aklog" path="/proc/fs/openafs/afs_ioctl" dev="proc" ino=4026532171 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:proc_afs_t:s0 tclass=file
type=AVC msg=audit(1485791285.438:1498): avc:  denied  { read } for  pid=3747 comm="aklog" name="afs_ioctl" dev="proc" ino=4026532171 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:proc_afs_t:s0 tclass=file

I have a working SELinux module that addresses this problem.

$ cat afsusers.te 
policy_module(afsusers,1.0.0)
gen_require(` type staff_t, user_t; ')
gen_require(` type proc_afs_t; ')
read_files_pattern({ staff_t user_t}, proc_afs_t, proc_afs_t)
afs_read_config(staff_t)
afs_read_config(user_t)

Loading the module lets 'aklog' read /etc/openafs/ThisCell as well as /proc/fs/openafs/afs_ioctl.

--- Additional comment from Jonathan Billings on 2017-01-31 21:26:48 UTC ---

I have to amend my custom module, I forgot to allow staff_sudo_t:

Here is the updated module .te:

policy_module(afsusers,1.0.1)
gen_require(` type staff_t, user_t, staff_sudo_t; ')
gen_require(` type proc_afs_t; ')
read_files_pattern({ staff_t user_t}, proc_afs_t, proc_afs_t)
afs_read_config(staff_t)
afs_read_config(staff_sudo_t)
afs_read_config(user_t)

--- Additional comment from Milos Malik on 2018-09-21 10:16:25 UTC ---

Following rules are missing:

:: [ 12:13:18 ] :: [   INFO   ] :: rlSESearchRule: checking rule 'allow staff_sudo_t afs_config_t : dir { getattr open search } [ ]'
:: [ 12:13:18 ] :: [   FAIL   ] ::   check permission 'getattr' is present (Assert: '1' should equal '0')
:: [ 12:13:18 ] :: [   FAIL   ] ::   check permission 'open' is present (Assert: '1' should equal '0')
:: [ 12:13:18 ] :: [   FAIL   ] ::   check permission 'search' is present (Assert: '1' should equal '0')
:: [ 12:13:18 ] :: [   INFO   ] :: rlSESearchRule: checking rule 'allow staff_sudo_t afs_config_t : file { getattr open read } [ ]'
:: [ 12:13:18 ] :: [   FAIL   ] ::   check permission 'getattr' is present (Assert: '1' should equal '0')
:: [ 12:13:18 ] :: [   FAIL   ] ::   check permission 'open' is present (Assert: '1' should equal '0')
:: [ 12:13:18 ] :: [   FAIL   ] ::   check permission 'read' is present (Assert: '1' should equal '0')

# rpm -qa selinux-policy\*
selinux-policy-mls-3.13.1-227.el7.noarch
selinux-policy-3.13.1-227.el7.noarch
selinux-policy-sandbox-3.13.1-227.el7.noarch
selinux-policy-targeted-3.13.1-227.el7.noarch
selinux-policy-devel-3.13.1-227.el7.noarch
selinux-policy-doc-3.13.1-227.el7.noarch
selinux-policy-minimum-3.13.1-227.el7.noarch
#

--- Additional comment from Lukas Vrabec on 2018-09-23 13:09:29 UTC ---

Milos, 

what about staff_t? Could staff_t access afs_config_t ? AFAIK, we should allow it for users domains. 

Thanks,
Lukas.

--- Additional comment from Milos Malik on 2018-09-24 06:58:22 UTC ---

staff_t and user_t can access afs_config_t, but the reporter also mentions staff_sudo_t. See comment#1.

# rpm -qa selinux-policy\*
selinux-policy-3.14.3-4.el8.noarch
selinux-policy-targeted-3.14.3-4.el8.noarch
# sesearch -s staff_sudo_t -t afs_config_t -A
allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True
allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True
allow domain file_type:file map; [ domain_can_mmap_files ]:True
allow domain file_type:lnk_file map; [ domain_can_mmap_files ]:True
allow sudodomain file_type:filesystem getattr;
#

Comment 4 Milos Malik 2019-11-14 16:01:57 UTC
# rpm -qa selinux\* openafs\* | sort
openafs-1.8.5-1.el8.x86_64
openafs-client-1.8.5-1.el8.x86_64
openafs-krb5-1.8.5-1.el8.x86_64
selinux-policy-3.14.3-24.el8.noarch
selinux-policy-targeted-3.14.3-24.el8.noarch
# ls -dZ /etc/openafs
system_u:object_r:afs_config_t:s0 /etc/openafs
# ls -dZ /etc/openafs/*
    system_u:object_r:afs_config_t:s0 /etc/openafs/cacheinfo
unconfined_u:object_r:afs_config_t:s0 /etc/openafs/CellServDB
    system_u:object_r:afs_config_t:s0 /etc/openafs/CellServDB.dist
    system_u:object_r:afs_config_t:s0 /etc/openafs/CellServDB.local
    system_u:object_r:afs_config_t:s0 /etc/openafs/ThisCell
#

# sesearch -s staff_t -t proc_afs_t -A
allow staff_usertype proc_afs_t:dir { getattr open search };
allow staff_usertype proc_afs_t:file { getattr ioctl lock open read };
# sesearch -s user_t -t proc_afs_t -A
allow user_usertype proc_afs_t:dir { getattr open search };
allow user_usertype proc_afs_t:file { getattr ioctl lock open read };
#

$ id
uid=1000(staff-user) gid=1000(staff-user) groups=1000(staff-user) context=staff_u:staff_r:staff_t:s0-s0:c0.c1023
$ aklog
aklog: Can't get information about the local cell.
$ aklog -d
aklog: Can't get information about the local cell.
$ sudo aklog
[sudo] password for staff-user: 
aklog: Can't get information about the local cell.
$ sudo aklog -d
aklog: Can't get information about the local cell.
$

$ id
uid=1001(user-user) gid=1001(user-user) groups=1001(user-user) context=user_u:user_r:user_t:s0
$ aklog 
aklog: Can't get information about the local cell.
$ aklog -d
aklog: Can't get information about the local cell.
$

Unfortunately, the output of aklog does not change if SELinux is set to permissive, which means that SELinux is not blocking the access.

Comment 6 Lukas Vrabec 2019-11-14 16:15:47 UTC
Thank you Milos. Closing as CURRENTRELEASE.

Comment 7 Jonathan Billings 2019-11-14 16:56:19 UTC
Just adding, I actually tested this with a configured OpenAFS system, and a user with a user_u context can get AFS tokens without any extra settings.

Comment 8 Milos Malik 2019-11-14 18:08:35 UTC
Thank you, Jonathan.


Note You need to log in before you can comment on or make changes to this bug.