On Fri, Sep 3, 2021 at 1:32 PM Stephen Gallagher <sgallagh(a)redhat.com&gt; wrote: I'm only seeing two AVC's which repeat but not a lot... Sep 03 14:27:09 fovo.local audit[6300]: AVC avc: denied { write } for pid=6300 comm="fprintd" name="wakeup" dev="sysfs" ino=28044 scontext=system_u:system_r:fprintd_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=0 Sep 03 14:27:09 fovo.local audit[6300]: AVC avc: denied { write } for pid=6300 comm="fprintd" name="persist" dev="sysfs" ino=28037 scontext=system_u:system_r:fprintd_t:s0 tcontext=system_u:object_r:sysfs_t:s0 tclass=file permissive=0 But enforcing=0 makes the boot time under 9s which is... awesome. Better than 34. I get more AVC's with enforcing=0, in fact... oh my that's a lot of selinux bugs reported already against 35 https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASS... But fprintd doesn't show up in any. So I will change the component to selinux-policy. -- Chris Murphy

On Fri, Sep 3, 2021 at 5:59 PM Adam Williamson <adamwill(a)fedoraproject.org&gt; wrote: No. Removed: 2021-09-03T18:23:01-0600 DEBUG ---> Package fprintd.x86_64 1.92.0-2.fc35 will be erased 2021-09-03T18:23:01-0600 DEBUG ---> Package fprintd-pam.x86_64 1.92.0-2.fc35 will be erased and the slow boot problem remains (with selinux still enforcing). -- Chris Murphy

Stephen Gallagher writes: I've watched SELinux come into existence, and its evolution over the years. It's clear to me that SELinux, let's say diplomatically, hasn't lived up to its expectations. The expectations in questions would be: it has an established mindshare; and software package maintainers can easily write, have clear documentation to follow, and ship selinux policies for their packages. Has this been happening? Of course not. Can anyone ever see this happening? Nope. Instead what we have now is siloed selinux package maintainance, with the selinux package responsible for constantly revising and updating a SYSTEMWIDE security policy, covering ALL packages in the distribution, in addition to popular software packages that are often installed, but not a part of the core distribution. Does this state of affair seem logical to anyone? SELinux maintainers can't be expected to be familiar what each and every package does, and constantly stay up to date with any updates in this area. This situation will never improve. Stuff will continue to break, with selinux. It will have to be constantly fixed. Hopefully. If it can be fixed in the first place. A more sensible approach would be for individual package developers and maintainers install their package's selinux policy together with the package, and maintain it. That makes too much sense, doesn't it? But it will never happen. Maybe my Google skills are rusty. Maybe my brain has atrophied. But I don't see, speaking very generally, how can anyone can avoid pouring a massive amount of time into figuring out how to write an SELinux policy for a package whose inner workings they can understand. SELinux's policy file syntax is unlike any other syntax of any other configuration system I know off. I searched, but could not find any tutorial or any sort of a guide to writing SELinux policies, or explain what /any/ of the cryptic statements in the existing selinux policy files do. Are you a package maintainer? Ok: please write an selinux policy for your package. Let me know when that's done. If one wants to learn how to write an rpm spec file, one can actually find useful documentation, even entire books on it. Although some of the info there is somewhat outdated, it's more than enough to get started, and learn enough to be able to figure out the missing pieces. Can someone post a link to the SELinux equivalent to the "Maximum RPM" book? Nobody was surprised more than me when I was able to cobble together an selinux policy file from scratch that allowed me to install and run my library, with a network server daemon. But it took over a week. It should've taken five minutes. That's what it actually took to physically type it. But it took over a week of frantic digging all over every corner of the intertubes, and countless cycles of "enable enforcing, wait until something breaks, look at the AVC message, grep the existing policy files for something that seems to define the capabilities that are missing, add them the policy file, recompile and reinstall it. This is not a practical way of implementing an SELinux policy. Only Fedora, IIRC, has selinux enabled by default. None of the other distributions have it turned on out of the box. Maybe someday SELinux has ample documentation, and is easy to configure and set up, for a given package, by the package's maintainers with just a minimal learning effort. Maybe someday there will no longer be a need to have a dedicated team of gurus who are the only ones that really know how it work, in order to support it. Until such day arrives Fedora will continue to be dragged down, and hobbled by having to have SELinux enabled by default.

Miroslav Suchý writes: You did that 7 years ago, according to change history. Today, I count >50k packages in Fedora. I'm going to wild guess that the number that install their own policy files is probably under a hundred. Based on nothing more than my gut feeling. Everything else falls under the shoulders of the global selinux-policy-targeted package to support. Let's suppose that you are a maintainer of some software package that builds and installs on Fedora, but fails to run with multiple AVC. You have a general awareness of selinux and what's it's all about. You even understand, more or less, what security contexts are, and what "ls -Z" tells you. So, you want to provide a policy files? How long will it take you to figure out how to do that? As I mentioned in my case it was a week, calendar time; and may be about 8 hours of total brainpower expended. In the grand scheme of things this may not be too bad, but I do have a problem with how I ended up finally writing that thing, and I didn't really walk away with it feeling that I actually learned anything. I didn't find a lot of useful reference material. Nothing like the web version of "Maximum RPM", which I used to learn how to package stuff using rpm. I was hoping for something similar for SELinux, but I came away disappointed. There are no manual pages or documentation to be found, in either selinux-policy-targeted or selinux-policy devel. The biggest collection of information I could find was one single page: https://selinuxproject.org/page/RefpolicyWriteModule – that's pretty much all that I had to work with, together with other scraps and tidbits from whatever I could find in Google, most of which was outdated. Also by looking at random files in the selinux packages. Even though I wound up with something that made those AVCs go away, I don't have a lot of confidence that the policy is as stringent as it should be. And now looking back at my policy file, and comparing it with that wiki page, I see that: 1) Somehow I had to learn about the "require" directive, and which requirements I need to pull into my policy file. 2) Somehow I had to figure out what domain_auto_trans(), type_transition() did, to make my package work. I wrote this policy file two years ago. I no longer remember what they actually do. A Google search for "domain_auto_trans site:selinuxproject.org" finds a wiki page where it's mentioned in a cryptic comment, and that's pretty much it. A search for "type_transition" gets an actual wiki page, but I just read it and it's all a foreign language to me now. 3) I also see that my cobbled policy has a "fs_associate_tmpfs" and "kernel_dgram_send", and a metric ton of others that have no hits at all, in what I understand to be is the reference SELinux site. They must be macros defined in Fedora's selinux policy file. I did a global Google search. The only hits I found were on http://oss.tresys.com/, which, I suppose, is progress. Here's what I wrote, back in the stone ages: https://raw.githubusercontent.com/svarshavchik/libcxx/master/packaging/fe... This is what I ended up doing, to make my AVCed go away. Someone can tell me whether this looks right, or is a horrible, horrible mess. A. It's a horrible mess. Sorry, but that's what the best I could do using publicly available information. I don't think I'm dumber than the next guy, but I'm open to be proven wrong. Until that time, this must mean that someone who's unfamiliar with SELinux will end up making a horrible mess, for the crime of attempting to make their software work on Fedora. B. This looks right. How many people can raise their hand and say that, today, they understand what every part of this does (I'm keeping my hand down). And would you say that it's reasonable to expect anyone who wants to develop on Fedora, and make their non-trivial software package work on Fedora, with SELinux, to figure out how to write this goo? I can see why there constant problems with SELinux issues in Fedora. Few understand it, outside of those who work on the core selinux package itself. SELinux has been around for a long time, and I would expect that these things to have been ironed out by now. The fact that it's not indicates a conceptual problem somewhere. Does this really scale? Does it make sense for Fedora to continue to grow, but the task of carrying selinux in working order, for the /entire/ distribution falling on the same set of shoulders, on one package? I would argue that it makes much more sense for packages to install their own policy files, that are maintained and updated by the package, but I don't see this happening any time soon. So, what's the point of me writing all this? I guess the point is that I read someone reporting a bunch of SELinux related breakage in F35; and I was wondering how it's a shame how the follow-up is to create more bugs in Bugzilla which, of course, won't stop something else breaking again, for the same underlying reasons why this broke this time.

On 2021-09-05 12:19 a.m., Peter Boy wrote: How is Fedora falling behind? In what way? What problems have you actually had with selinux? Yes, there appears to currently be a slowdown caused by selinux *in an unreleased version*. I'm sure it will be fixed before F35 is released.

On 05/09/2021 09:55, Philip Rhoades via devel wrote: In over 10 years with Fedora, I've only had some SELinux problems. Fixed quickly after filling out RHBZ report. -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org)

I watch Distrowatch in an occasional way. It is certainly not the most reliable indicator, unquestioningly. But is is one among others. Currently Fedora ranks 10th, one place ahead of Suse, a distro that has long been considered nearly "dead" and has suffered greatly under Novell. And if you look at sites like stackexchange or serverfault, it's very rarely about Fedora. see https://bugzilla.redhat.com/show_bug.cgi?id=1900869 https://bugzilla.redhat.com/show_bug.cgi?id=1900888 Debian (selinux variant) solved the issue a long time ago. I'm sure our maintainers do what they can and don't take any issue lightly. As Sam wrote it has grown into a conceptual issue. I’m sure, too. With my comments, I (and possibly Sam) was not solely concerned with the slowdown problem. This is rather an expression of a larger problem (overloaded maintainers, missing / insufficient information, outdated documentation, etc) that should be addressed.

On 05/09/2021 13:11, Peter Boy wrote: Only a few packages (mostly different daemons) require a separate SELinux policy. None of my 68 packages require this for example. -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org)

As I detailed in the first sentence, Distrowatch is certainly not an exact metric measurement. But it does show long-term trends (over decades) that are not pure coincidence or artifacts of errant bots or fashionable trends either. This includes that Debian, Ubuntu and Fedora are among the stable "big" distributions and also that the gap between Fedora and the other two is constantly widening. And other signs show the same picture. But forget Distrowatch. That's not the issue I'm concerned about (and obviously Sam is too), but merely an illustration of consequences. The main question is, can we cope with the increased number of packages with the existing structure of centralizing all SELinux matters in a few packages separate from the application software. And this includes how we can keep the related information and documentation up to date and accurate. The example of Telnet is, indeed. But unfortunately not the other examples. My bug report (e.g. #1900869) is from November 2020 and still open. It renders a software that we "officially" distribute as part of Fedora essentially unusable. And this for more than 3 releases now. This is current and not really satisfying. And others have similar problems with other current software. Just to clarify and avoid misunderstandings: I'm not saying our maintainers aren't doing their work, on the contrary. This is a structural or conceptual concern. It worked adequately in the beginning, but may now be inappropriate after years of growth.

On Sun, Sep 5, 2021 at 12:07 PM Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote: And for what it's worth, the SUSE distribution family *is* adopting SELinux too. Android and Chrome OS *both* use SELinux too. Those latter two make up the overwhelming majority of Linux deployments, so clearly SELinux as a technology is a problem. Red Hat is also *already* modularizing the SELinux policy, they've got an objective to do that over the next few RHEL releases, which has been slowly landing in Fedora over time, too. They started that work in 2018 and it's been going on in the background. For example, libvirt's SELinux policy is being broken out and integrated into the upstream project right now. -- 真実はいつも一つ！/ Always, there's only one truth!

On Mon, 2021-09-06 at 02:08 -0400, Neal Gompa wrote: I was about to ask you what you meant here, but I soon realized it was a typo. I don't think anyone have understood it other way.

Indeed, and without any doubt! And that's why the solution Philip mentions (previous posting), while common, is actually a temporary stopgap at best. And it is even more important to address the underlying problem that Sam Varshavchik so accurately described, JM2C.

On 05/09/2021 14:40, Nico Kadel-Garcia wrote: I know at least one who uses telnet to run an online BBS. SELinux saved this server from being hacked and rooted. -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org)

Vitaly Zaitsev via devel writes: Great. If only SELinux wasn't such a siloed domain; if only a great, overwhelming majority of Fedora package maintainers were able to write policies for their own packages and maintain it themselves because SELinux documentation was ample and easy to fllow; then these constant AVC failures would likely be a thing of the past.

Vitaly Zaitsev via devel writes: Which parts of the above describe, and explain, how to write the SELinux policy itself? Once it's written that's a great piece of documentation to follow, to explain how to package this policy. But this is putting the cart before the horse. The package maintainers have to actually understand how to write SELinux policies, first. The problem isn't the technical details of how to package an SELinux policy with the packge. The problem is the domain knowledge needed to write that SELinux policy in the first place. It's siloed mostly in the selinux package itself. I assert that the documentation above is not going to be useful to 95% of the package maintainers. A few of them will know how to write a policy, and then follow the above wiki. The rest will not. Prove me wrong. I posted this link before: https://raw.githubusercontent.com/svarshavchik/libcxx/master/packaging/fe... Where is the documentation that explains /all/ of the above, and what it means? I wrote that policy, of course, but even now, just a short time later, I can't for the life of me tell you where all that documentation is. Because there isn't, I had to figure out based on scraps of other selinux policies that I looked at, and based on my experience with other stuff that did NOT involve SELinux. You will not find any documentation that explains /all/ of that on https://selinuxproject.org And at most 5% of the above is explained in https://selinuxproject.org/page/RefpolicyWriteModule And until the state of the world is such that SELinux is not a siloed domain, that it's amply documented, and package maintainers have documentation that they can use to write their own policy, for the package that they fully understand and support, SELinux will continue to break random stuff, over and over again.

On Sun, Sep 05, 2021 at 09:19:20AM +0200, Peter Boy wrote: To be clear, the request is an initiative to get more per-package SELinux policies? I think that's a good goal, but remember the Council can't assign work. A Council objective generally means that we recognize an initiative that people are already there to do as something that's strategically important. This might meet the "strategically important" part, but in order to be an initiative it needs interested people to drive and implement. If we _have_ those people, I'll be happy to support! -- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

On Fri, Sep 3, 2021 at 12:52 PM Chris Murphy <lists(a)colorremedies.com&gt; wrote: So.... disable SELinux and time it?

On Fri, Sep 10, 2021 at 2:11 AM Marius Schwarz <fedoradev(a)cloud-foo.de&gt; wrote: It's an selinux issue. Fixed in Rawhide, waiting for an F35 build and then testing it. Interesting to note that there's such a thing as user AVCs and I guess (?) those don't show up in the journal with system AVCs. That might be why I never saw why the problem work around was enforcing=0. -- Chris Murphy