Re: Fixing denials
John Griffiths via selinux <[email protected]> Tue, 14 Jan 2025 17:25:24 -0500 (EST)
| Newsgroups | gmane.linux.redhat.fedora.selinux |
|---|---|
| Message-ID | <[email protected]> |
--===============7063947677567242157== Content-Type: multipart/alternative; boundary="----=_Part_19_27224716.1736893524335" ------=_Part_19_27224716.1736893524335 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit No offense taken. I started working with selinux I Fedora Core 4 in 2005. I've been through lots of changes. Running in permissive mode in a multiuser environment would certainly be problematic. Running as a single user with only one unknown should be much less so. We went from very laborious policy module creation to much easier with sealert and audit2allow and, apparently, back to being laborious. I always review the te file to see if it is reasonable and whether it opens any extraneous holes in security. So far. I've never seen a problem, but maybe I've been lucky. If the audit2allow and sealert give erroneous modules, then they should be deprecated. Until they are, I will continue to use them. The reason I am stepping back from the conversation is I am apparently behind the current wisdom and I am not particularly interested in going back to producing modules laboriously. ------=_Part_19_27224716.1736893524335 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit <html> <head> <meta name="viewport" content="width=device-width, initial-scale=1.0"> </head> <body> <span dir="ltr" style="margin-top:0; margin-bottom:0;">No offense taken.</span> <br> <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">I started working with selinux I Fedora Core 4 in 2005.</span> <br> <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">I've been through lots of changes.</span> <br> <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">Running in permissive mode in a multiuser environment would certainly be problematic. Running as a single user with only one unknown should be much less so.</span> <br> <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">We went from very laborious policy module creation to much easier with sealert and audit2allow and, apparently, back to being laborious.</span> <br> <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">I always review the te file to see if it is reasonable and whether it opens any extraneous holes in security. So far. I've never seen a problem, but maybe I've been lucky.</span> <br> <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">If the audit2allow and sealert give erroneous modules, then they should be deprecated. Until they are, I will continue to use them.</span> <br> <br><span dir="ltr" style="margin-top:0; margin-bottom:0;">The reason I am stepping back from the conversation is I am apparently behind the current wisdom and I am not particularly interested in going back to producing modules laboriously.</span> <br> </body> </html> ------=_Part_19_27224716.1736893524335-- --===============7063947677567242157== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline LS0gCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCnNlbGlu dXggbWFpbGluZyBsaXN0IC0tIHNlbGludXhAbGlzdHMuZmVkb3JhcHJvamVjdC5vcmcKVG8gdW5z dWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byBzZWxpbnV4LWxlYXZlQGxpc3RzLmZlZG9yYXByb2pl Y3Qub3JnCkZlZG9yYSBDb2RlIG9mIENvbmR1Y3Q6IGh0dHBzOi8vZG9jcy5mZWRvcmFwcm9qZWN0 Lm9yZy9lbi1VUy9wcm9qZWN0L2NvZGUtb2YtY29uZHVjdC8KTGlzdCBHdWlkZWxpbmVzOiBodHRw czovL2ZlZG9yYXByb2plY3Qub3JnL3dpa2kvTWFpbGluZ19saXN0X2d1aWRlbGluZXMKTGlzdCBB cmNoaXZlczogaHR0cHM6Ly9saXN0cy5mZWRvcmFwcm9qZWN0Lm9yZy9hcmNoaXZlcy9saXN0L3Nl bGludXhAbGlzdHMuZmVkb3JhcHJvamVjdC5vcmcKRG8gbm90IHJlcGx5IHRvIHNwYW0sIHJlcG9y dCBpdDogaHR0cHM6Ly9wYWd1cmUuaW8vZmVkb3JhLWluZnJhc3RydWN0dXJlL25ld19pc3N1ZQo= --===============7063947677567242157==--