Re: F35 3x slower boot than F34

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Miroslav Suchý writes:

Dne 04. 09. 21 v 17:28 Sam Varshavchik napsal(a):
Are you a package maintainer? Ok: please write an selinux policy for your package. Let me know when that's done.

https://pagure.io/copr/copr/blob/main/f/selinux

You are welcome.

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/fedora/libcxx.te

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.

Attachment: pgpNC5onMnD76.pgp
Description: PGP signature

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux