security_getenforce(3)

πŸ’– security_getenforce(3) β€” the SELinux API documentation, bestie edition πŸ’–

okay so welcome to security_getenforce(3), part of the SELinux API documentation ✨ this is the whole little friend group of functions that get or set the enforcing state of SELinux, plus a couple of policy-vibe-checkers. let's get into it 🫢


✨ NAME ✨

security_getenforce, security_setenforce, security_deny_unknown, security_reject_unknown, security_get_checkreqprot β€” get or set the enforcing state of SELinux πŸ‘‘


🌸 SYNOPSIS 🌸

#include <selinux/selinux.h>

int security_getenforce(void);

int security_setenforce(int value);

int security_deny_unknown(void);

int security_reject_unknown(void);

int security_get_checkreqprot(void);

like, five whole functions, one tiny header. slay πŸ’…


πŸ¦‹ DESCRIPTION πŸ¦‹

okay so here's the tea on each one, one by one, no skipping, i promise πŸ“

security_getenforce() returns 0 if SELinux is running in permissive mode, 1 if it is running in enforcing mode, and -1 on error. it's giving "are we actually enforcing or are we just cosplaying" πŸ’€

security_setenforce() sets SELinux to enforcing mode if the value 1 is passed in, and sets it to permissive mode if 0 is passed in. on success 0 is returned, on error -1 is returned. so like, one argument, two possible vibes. periodt.

security_deny_unknown() returns 0 if SELinux treats policy queries on undefined object classes or permissions as being allowed, 1 if such queries are denied, and -1 on error. undefined stuff? either we're chill about it or we're not 🌈

security_reject_unknown() returns 1 if the current policy was built with handle-unknown=reject and SELinux would reject loading it, if it did not define all kernel object classes and permissions. in this state, when selinux_set_mapping() and selinux_check_access() are used with an undefined userspace class or permission, an error is returned and errno is set to EINVAL. so like, strict mode. no notes, it will simply not let you in πŸ™ˆ

it returns 0 if the current policy was built with handle-unknown=allow or handle-unknown=deny. in this state, policy queries are treated according to security_deny_unknown(). -1 is returned on error. bestie it's literally just "which one of the three build flags was this policy raised with" energy πŸŽ€

security_get_checkreqprot() can be used to determine whether SELinux is configured to check the protection requested by the application or the actual protection that will be applied by the kernel (including the effects of READ_IMPLIES_EXEC) on mmap and mprotect calls. it returns 0 if SELinux checks the actual protection, 1 if it checks the requested protection, and -1 on error. requested vs actual. the way that these two are NOT the same thing because READ_IMPLIES_EXEC is out here doing the most 😭 main character behaviour fr fr πŸ”₯


⭐ SEE ALSO ⭐


and that's the whole page bestie, you ate it πŸ’…βœ¨ this icon of a manpage was brought to you by russell@coker.com.au, dated 1 January 2004 β€” yes, 2004, it's vintage, it's iconic, we stan a classic πŸ‘‘πŸ¦‹πŸŒΈπŸ’–

πŸ“¦ where this page comes from