selinux September 2021

selinux@lists.fedoraproject.org

7 participants
5 discussions

certmonger post-save scripts & certmonger_unconfined_t domain
by Sam Morris 06 Jun '24

06 Jun '24

Certmonger allows for the configuration of a post-save command to be run after it has obtained new certificates. This can be used to copy the key & certificates out of wherever certmonger is allowed to put them, and save them elsewhere with a particular owner/group, combine the certificate & chain into a single file as required by some software, etc. The problem comes with SELinux which prevents my post-save scripts from being able to do all of that. I thought the solution was to give the scripts the context of certmonger_unconfined_exec_t, which would cause a transition to the certmonger_unconfined_t domain which is as its name suggests unconfined; but I can't get this to work. I'm trying to use runcon to simulate certmonger executing a fake script: # cat /tmp/fakescript #!/bin/bash set -eu id -Z # /tmp/fakescript unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 # ls -Z /tmp/fakescript unconfined_u:object_r:certmonger_unconfined_exec_t:s0 /tmp/fakescript # runcon system_u:system_r:certmonger_t:s0 /tmp/fakescript runcon: ‘/tmp/fakescript’: Permission denied Here is the avc denial: ---- type=PROCTITLE msg=audit(27/04/21 16:16:47.156:153492) : proctitle=runcon system_u:system_r:certmonger_t:s0 /tmp/fakescript type=SYSCALL msg=audit(27/04/21 16:16:47.156:153492) : arch=x86_64 syscall=execve success=no exit=EACCES(Permission denied) a0=0x7ffd8aa768ab a1=0x7ffd8aa75888 a2=0x7ffd8aa75898 a3=0x0 items=0 ppid=177795 pid=177796 auid=sam.admin uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts5 ses=103 comm=runcon exe=/usr/bin/runcon subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(27/04/21 16:16:47.156:153492) : avc: denied { entrypoint } for pid=177796 comm=runcon path=/tmp/fakescript dev="dm-0" ino=33563064 scontext=system_u:system_r:certmonger_t:s0 tcontext=unconfined_u:object_r:certmonger_unconfined_exec_t:s0 tclass=file permissive=0 Even though: # sepolicy transition -s certmonger_t -t certmonger_unconfined_t certmonger_t @ certmonger_unconfined_exec_t --> certmonger_unconfined_t Diving in a little deeper, I can see that certmonger can execute the file: # sesearch -s certmonger_t -t certmonger_unconfined_exec_t -c file -p execute -A allow certmonger_t certmonger_unconfined_exec_t:file { execute execute_no_trans getattr ioctl map open read }; ... and that the file type is an entrypoint for the certmonger_unconfined_t domain: # sesearch -s certmonger_unconfined_t -t certmonger_unconfined_exec_t -c file -p entrypoint -A allow certmonger_unconfined_t certmonger_unconfined_exec_t:file { entrypoint execute getattr ioctl lock map open read }; ... and that transition is permitted from certmonger_t: # sesearch -s certmonger_t -t certmonger_unconfined_t -c process -p transition -A allow certmonger_t certmonger_unconfined_t:process transition; Which leaves me scratching my head, unsure why it doesn't work in practice... -- Sam Morris <https://robots.org.uk/> PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9

2 4

NFS and selinux context question
by Ed Greshko 28 Sep '21

28 Sep '21

Hi, The configuration is a Fedora NFS server holding the home directories of Fedora clients. So, all Fedora. Example: A user on the client creates a ~/.cert directory. Looking at the directory from the server side we see. [djensen@f35ser ~]$ ls -Zd .cert system_u:object_r:home_cert_t:s0 .cert On the client side the user sees [djensen@f35k ~]$ ls -Zd .cert system_u:object_r:nfs_t:s0 .cert Is there a way the client side can show the actual selinux context that is being enforced on the server side? -- Nothing to see here

4 6

Custom unix local socket type
by MK 15 Sep '21

15 Sep '21

Hello! I created a small server app module that I included a custom socket type in: type plazerine_socket_t; typeattribute plazerine_socket_t file_type, non_auth_file_type, non_security_file_type; This is for a unix local stream socket, for which there is a file context rule: semanage fcontext -a -t plazerine_socket_t /usr/local/etc/plazerine/msgin The server executable is labeled 'plazerine_exec_t', and the process derived from it transistions to 'plazerine_t'. However, when it creates and opens the socket, the file always ends up typed `plazerine_exec_t` (requiring various socket oriented permissions on that type). There's no AVC denial to interpret (which is how I've mostly found my way around), and this isn't deal breaking for me -- in a sense having a separate type for the socket may be sort of redundant. OTOH, it would provide some more fined grained depending on how complex the system using the exec type is. Is there a right way to do this? I notice via `seinfo -t` there is a handful of what seem by name to be custom socket types, and they are defined typeattribute wise the same way I've done it above. This is on a policy v.33 fedora system, targeted, enforcing. - MK

1 0

Re: "semanage boolean -l" shows separate strings
by Petr Lautrbach 07 Sep '21

07 Sep '21

Samuel Fusato <samuelfusato(a)gmail.com> writes: >> Hope you are well. When you have time, can you kindly let me know why the >> command "semanage boolean -l" shows "homedirs" and "home dirs" on the >> Description of the booleans? Examples: >> >> [root@workstation ~]# semanage boolean -l | grep httpd_enable_homedirs >> httpd_enable_homedirs (off , off) Allow httpd to enable >> *homedirs* >> >> [root@workstation ~]# semanage boolean -l | grep use_nfs_home_dirs >> use_nfs_home_dirs (off , off) Allow use to nfs *home dirs* >> >> Why is there not a sort of standardization there? >> In this case descriptions are generated from boolean names. The algorithm is simple - the boolean name is split using '_', first world is usually subject then perm then object. 'Allow' is at adaed to the beginning and 'to' is added between subject and perm. It generally works reasonably well: httpd_enable_homedirs -> Allow httpd to enable homedirs but use_nfs_home_dirs -> Allow use to nfs home dirs If you want better descriptions, you can install `selinux-policy-devel`: # dnf install selinux-policy-devel # semanage boolean -l | grep httpd_enable_homedirs httpd_enable_homedirs (off , off) Allow httpd to read home directories As for the boolean names - httpd_enable_homedirs vs use_nfs_home_dirs - I don't know why they are inconsistent. It might be related to the fact that `homedirs` could be a feature for httpd, but it home dirs when we talk about nfs. I don't know. Petr

1 0

Failed to resolve typeattributeset
by lejeczek 06 Sep '21

06 Sep '21

Hi guys. I'm trying to remove an old custom module but I fail: -> $ semodule -X 300 -r charonsystemd-mine libsemanage.semanage_direct_remove_key: Removing last charonsystemd-pawel module (no other charonsystemd-pawel module exists at another priority). Failed to resolve typeattributeset statement at /var/lib/selinux/targeted/tmp/modules/400/me-libvirt/cil:5 semodule: Failed! Care to share your thoughts? many thanks, L

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

selinux September 2021