-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Zeuthen wrote: > On Thu, 2008-01-03 at 14:45 -0500, Dimi Paun wrote: >> On Thu, 2008-01-03 at 14:09 -0500, David Zeuthen wrote: >>> I'm not running SELinux enforcing mode on any of my machines.. >> That's too bad -- it's hard to gage the usability of a system >> without it on, since it is enabled by default for most people. > > Well, the kernel bits of SELinux is great. The user space bits never > ever worked for me; neither as a user, nor RPM package maintainer and > definitely not as an upstream developer of highly modular software that > is designed to be locked down (e.g. hald and it's helper processes) > > Some problems from a 50,000 feet point of view > > - the policy is way too complicated; really, I think it's kinda futile, > at this point, to attempt to lock down bits that are not even > network-facing. > > As a result someone decided "oh, we're just going to let people turn > of it". And this is where we are now. Total cop out. Might as well > not ship it. > > Seriously. Just go ahead and look at the policy. No wonder it often > doesn't work given it's so complex. > > - the policy is centrally maintained; e.g. the maintainer of the policy > for hald (Dan Walsh) and, hey, all of the policy often have to guess > how to lock things down and often, despite Dan being a great > engineer, these guesses are just wrong. Seriously, no one can blame > Dan for this - you cannot expect a single person to know all the > kinks of all the software in Fedora. > > -> Ideally every upstream project can maintain it's own policy. That > has the nice side effect of, gosh, teaching other distributions > about the benefits of MCA. > > -> If upstream don't want to include SELinux policy, just include > it as a patch in the RPM > > Typical responses: > - "rpm cannot handle SELinux policy": <- bullshit; it's not much > different from other file meta data; do we store file modes and > permissions centrally too? No. > > - "uh, then you would have deps on policy": Like, for example, the > policy for hald would depend on the policy for, say, dbus. Not > a problem, the real world contains dependencies already and most > these deps are handled just fine already by the upstream > projects. > > I'm not even going to go into the language used for defining policy. > > In short, SELinux just doesn't work for me. I'm not denying it may work > well on a tightly-controlled servers where features never change (e.g. > RHEL). > > David > > Well there are several problems with allowing the individual maintainers manage their own policy. #1 they won't. #2 when they do, they do a very bad job of it. Or basically just end up with unconfined_t. #3 The tools are too slow. Having 100 semodule -i will cause the installation to take for ever. #4 Interaction between confined domains does not work well when multiple maintainers writing policy. sendmail, procmail, spamassassin, clamav, postfix, qmail, mailserver, pyzor ... All interact in very complex ways. #5 conflicts on file_context directories/files David, You are writing an application that is trying to do things on behalf of the user as root. These activities will cause conflicts and need to be well controlled. So you are likely to run into problems with SELinux. Jesse, what problems are you seeing that needs to run in permissive mode? I know about the chroot environments and there is not a good answer to this. Placing of the file context down without loading the SELInux policy would help in this environment. But we would still have problems with applications running in post install, not getting the correct context. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkd9XKQACgkQrlYvE4MpobNNxgCg6RQ5obJYQlybtl275oLfpdD1 pkwAoKOpjXe5mubk7MsUpBRNE6k1YGzp =jfZz -----END PGP SIGNATURE----- -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
