{"id":151,"date":"2019-12-12T19:25:59","date_gmt":"2019-12-12T19:25:59","guid":{"rendered":"http:\/\/www.martin-rdz.de\/?p=151"},"modified":"2021-12-23T10:36:07","modified_gmt":"2021-12-23T10:36:07","slug":"selinux-systemd-and-python-virtual-environments","status":"publish","type":"post","link":"http:\/\/www.martin-rdz.de\/index.php\/2019\/12\/12\/selinux-systemd-and-python-virtual-environments\/","title":{"rendered":"SELinux, systemd and python virtual environments"},"content":{"rendered":"\r\n

Recently I wanted to configure a gunicorn<\/a> backend at our newest server. The aim was to run a flask-based python application using a virtual environment<\/a> in a users home. The machine is running recent Red Hat 8<\/a> and the setup of systemd was straightforward and well documented in the internet (e.g. here<\/a>). However, after<\/p>\r\n\r\n\r\n\r\n

systemctl daemon-reload\r\nsystemctl enable ourservice\r\nsystemctl start ourservice<\/pre>\r\n\r\n\r\n\r\n
a strange permission denied error occurred (also journalctl<\/code>\u00a0helps in that context).<\/p>\r\n\r\n\r\n\r\n
After rechecking the file permission several times I finally remembered, that Red Hat now runs runs SELinux<\/a>. It allows even finer access control for files, resources and actions using policies. The current status of SELinux can be shown with sudo sestatus<\/code>. For testing reasons, all policies can be set to permissive using sudo setenforce permissive<\/code>. The contexts of a file can be inspected with ls -Z file1<\/code>.<\/p>\r\n
To debug an process that fails, the \/var\/log\/audit\/audit.log<\/code> file is the first place to look at. The audit2why<\/code> tool translates the error messages to a more understandable format:<\/p>\r\n\r\n\r\n\r\n\r\n\r\n
>\r\nsudo cat \/var\/log\/audit\/audit.log | grep gunicorn | audit2why<\/pre>\r\n\r\n\r\n\r\n
Afterwards the audit2allow<\/code> utility can generate rules, that would allow the denied operations:<\/p>\r\n\r\n\r\n\r\n
>\r\nsudo cat \/var\/log\/audit\/audit.log | grep gunicorn | audit2allow -M custom_rule<\/pre>\r\n\r\n\r\n\r\n
These rules are now stored in the format of an type enforcement (custom_rule.te<\/code>) file and a policy package which can be activated using semodule -i custom_rule.pp<\/code>.<\/p>\r\n\r\n\r\n\r\n
Likely this process has to be repeated, as different kinds of operations might be denied.<\/p>\r\n\r\n\r\n\r\n
For our setup the final type enforcement file looked like<\/p>\r\n\r\n\r\n\r\n
module custom_rule 1.0;\r\n \r\nrequire {\r\n        type init_t;\r\n        type unconfined_exec_t;\r\n        type user_home_t;\r\n        class file { append execute execute_no_trans ioctl map open read setattr };\r\n        class lnk_file { getattr read };\r\n}\r\n \r\n#============= init_t ==============\r\n#!!!! This avc is allowed in the current policy\r\nallow init_t unconfined_exec_t:file { execute open read };\r\nallow init_t user_home_t:file setattr;\r\n \r\n#!!!! This avc can be allowed using the boolean 'domain_can_mmap_files'\r\nallow init_t user_home_t:file map;\r\n \r\n#!!!! This avc is allowed in the current policy\r\n#!!!! This av rule may have been overridden by an extended permission av rule\r\nallow init_t user_home_t:file { append execute execute_no_trans ioctl open read };\r\n \r\n#!!!! This avc is allowed in the current policy\r\nallow init_t user_home_t:lnk_file { getattr read };<\/pre>\r\n\r\n\r\n\r\n
The type enforcement rule can be compiled manually<\/p>\r\n\r\n\r\n\r\n
checkmodule -M -m -o custom_rule.mod custom_rule.te\r\nsemodule_package -o custom_rule.pp -m custom_rule.mod\r\nsudo semodule -i custom_rule.pp<\/pre>\r\n\r\n\r\n\r\n
Further useful resources<\/h5>\r\n\r\n\r\n\r\n