On Thu, 2025-11-13 at 08:12 -0500, Sam Varshavchik wrote: > Conceptually, a complicated technical ecosystem like SELinux can only > meaningfully scale if the barrier of entry is low enough for the upstream > sources to be able to easily supply the SELinux policy, as part of the > package. > > Originally, it was expected that SELinux will become very popular and take > over the Linux scene by storm. It was thought that there wasn't much need to > provide a rich set of resources for learning how to use SELinux. After all, > everyone will simply have to deal with it, if they wish to play with the big > boys.
That a scheme dreamt up by some American three-letter-organisation with a bad reputation wouldn't be popular, or user-friendly... Who woulda thunk?! The idea behind why/how it works isn't that bad. It seems a very good idea to only let the web server serve appropriately classed files, though that could be accomplished by sensibly configuring the server, and debugging it to not be allowed to read from the /etc directory, for instance. Likewise with other services. And not creating files world- accessible when they don't need to be. Whether that be by you, or some stupid blogging software creating everything world-writeable by the web server in an unprotected filepath. But the implementation is hideous, and dependent on a filing system that can hold the additional access information along with the file. I can well imagine that a spy agency would be fine working with a system where you get to individually declare particular access rights to individual files, per file, but that's not how general users do things. We don't declare this file top secret, most secret, or unclassified. We don't develop convoluted access lists for which people can read or modify a particular file (boss, wife, kids, co- workers in my team). Windows already had similar kinds of fancy access controls, but it makes little coherent sense to anybody outside of an organisation that deals with secrets. AppArmor seems far less painful, in principle. Instead of strange policies applied to files, files in certain paths have restrictions imposed on them (e.g. web serving has to be done from certain paths, and files simply placed in the webserver path can be served). It doesn't matter what file system is used. SELinux tries to behave like that, slightly. When you create a file in special places, default access contexts are applied to it to allow the expected programs to use such files. But actually accessing those files relies on the contexts stored in them, not where they're stored. And should something get the contexts wrong, you're stuffed. Does SELinux actually do anything beneficial for the average (*) person with a PC that cannot be remotely contacted? Potentially it could, but does it "actually"? And could other, simpler, schemes do the job just as well? * The average person has no publicly responding servers. Is at home, not on public WiFi. And since the end of dial-up, is behind a router which doesn't forward unexpected connections though it to your PC. -- uname -rsvp Linux 3.10.0-1160.119.1.el7.x86_64 #1 SMP Tue Jun 4 14:43:51 UTC 2024 x86_64 (yes, this is the output from uname for this PC when I posted) Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. -- _______________________________________________ users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
