Re: F24 System Wide Change: Default Local DNS Resolver
On 12/17/2015 10:19 AM, Harald Hoyer wrote: > On 07.12.2015 20:57, Paul Wouters wrote: >> On Mon, 7 Dec 2015, Matthew Miller wrote: >> >>> I read your whole post. Those possibilities seem pretty limited, from >>> the point of view of serious regressions in Fedora usability. It isn't >>> that I "like" Fedora being less than technically correct (especially >>> around security-related features), but I don't think we can discount >>> the prevalence of "broken" schemes in the real world. >> >> But you gain nothing with waiting. There is no "fix" to wait for. Those >> stolen domains are broken and they will start to fail. The only difference >> could be that fedora won't be the first where this breaks on, but I >> thought "First" was one of our motto's ? >> >>> I don't really care about that. I care that we pick the solutions that >>> are best for our users. >> >> Supporting DNSSEC per default is best for the user. Not enabling DNSSEC >> is not a serious option. We delayed this feature a few times to ensure >> we would get better integration with gnome and VPNs so that we could >> address the _real_ problems. >> >> People using stolen or made up domain names is not a use case that can >> be supported anymore with Secure DNS. > > If it causes problems you have no time to fix, you will do "selinux=0 > dnssec=0" Whoops. Why "selinux=0"? Do you think it would be better to tell people to set "enforcing=0" and collect AVCs with a report instead of saying "selinux=0"? > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org > -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: Packaging Icinga 2 requiring SELinux assistance
On 09/23/2015 01:57 PM, Alec Leamas wrote: > On 23/09/15 13:16, Petr Lautrbach wrote: >> On 09/22/2015 08:46 PM, Shawn Starr wrote: > >> However in long terms it's better to incorporate a package policy to >> the system policy. You can either file a bug against selinux-policy or >> try to contribute yourself using this [2] howto. > > That howto is somewhat sketchy if you (as me) are new to this. However, > Miroslaw has made some promises to improve it [3] Yeap. I will update "How to Contribute" section with more details and examples as my next step. Thx. > > Cheers! > > --alec > > [3] https://github.com/fedora-selinux/selinux-policy/issues/38 > > > > -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADS-UP] Please test kdbus in Rawhide!
On 07/31/2015 08:49 PM, Lennart Poettering wrote: On Thu, 30.07.15 19:57, Lennart Poettering (mzerq...@0pointer.de) wrote: Heya! I'd like to ask everybody to test kdbus on Rawhide. Josh thankfully added it to the Rawhide kernel packages, and our systemd RPMs come with built-in support, too now. If you are running an up-to-date Rawhide system adding kdbus=1 to your kernel command line is hence everything you need to run kdbus instead of dbus-daemon. (No additional RPMs need to be installed.) If you do, things should just work the same way as before, if we did everything right. By adding or dropping kdbus=1 to/from the command line you can enable kdbus or revert back to dbus1 on each individual boot. Quick update: We have released a new version of systemd now with all bugs reported here fixed. It's also in Rawhide already, but it might not have hit all mirrors yet. To download it directly, please use: http://koji.fedoraproject.org/koji/buildinfo?buildID=674692 And please remember to turn selinux at least into permissive mode when using this, or even turn it off entirely while testing (kdbus=1 selinux=0 on the kernel command line). As you probably know this is not only about a policy fix. We added a support for /sys/fs/kdbus in the latest rawhide policy builds to avoid unlabeled_t issues and we can better track all issues related to kdbusfs_t. But there is no a good policy fix in this state. It requires LSM/SELinux support and without this support it is a completely uncontrolled IPC mechanism. Also some mails about the kdbus development plans and timing would be helpful. Thanks. Mirek Thanks a lot to everybody who already tested this! Please test the new version, any feedback much appreciated! Lennart -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADS-UP] Please test kdbus in Rawhide!
On 08/06/2015 01:47 PM, Miroslav Grepl wrote: On 07/31/2015 08:49 PM, Lennart Poettering wrote: On Thu, 30.07.15 19:57, Lennart Poettering (mzerq...@0pointer.de) wrote: Heya! I'd like to ask everybody to test kdbus on Rawhide. Josh thankfully added it to the Rawhide kernel packages, and our systemd RPMs come with built-in support, too now. If you are running an up-to-date Rawhide system adding kdbus=1 to your kernel command line is hence everything you need to run kdbus instead of dbus-daemon. (No additional RPMs need to be installed.) If you do, things should just work the same way as before, if we did everything right. By adding or dropping kdbus=1 to/from the command line you can enable kdbus or revert back to dbus1 on each individual boot. Quick update: We have released a new version of systemd now with all bugs reported here fixed. It's also in Rawhide already, but it might not have hit all mirrors yet. To download it directly, please use: http://koji.fedoraproject.org/koji/buildinfo?buildID=674692 And please remember to turn selinux at least into permissive mode when using this, or even turn it off entirely while testing (kdbus=1 selinux=0 on the kernel command line). As you probably know this is not only about a policy fix. We added a support for /sys/fs/kdbus in the latest rawhide policy builds to avoid unlabeled_t issues and we can better track all issues related to kdbusfs_t. But there is no a good policy fix in this state. It requires LSM/SELinux support in kernel and without this support it is a completely uncontrolled IPC mechanism. Also some mails about the kdbus development plans and timing would be helpful. Thanks. Mirek Thanks a lot to everybody who already tested this! Please test the new version, any feedback much appreciated! Lennart -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [HEADS UP] SELinux policy store migration in Rawhide
On 07/16/2015 10:10 AM, Petr Lautrbach wrote: Hi everybody, we will do an update of SELinux userspace tools to 2015-02-02 release and selinux-policy packages as it was proposed in SELinux policy store migration Fedora system wide change [1]. Hi all, good news are here. Yesterday, we did rawhide and F23 builds for SELinux userspace tools and SELinux policy containing all changes related to SELinux policy store migration [1]. So now they are available from rawhide and F23 repositories by default. Together with that your help, questions, bugs and feedback will be appreciated Regards, Miroslav What does it mean for you: 1. You use only Fedora default SELinux policy. You shouldn't notice any change but some performance improvements during regular policy updates. 2. You have local changes in policy like changed booleans, adjusted SELinux users, added or changed port or file contexts definitions made via semanage command. You shouldn't notice any change. All local modifications should be handled by migration process during packages update. You can backup your setting using the command below before the update will happen. # semanage export -f semanage.mods 3. You have your local SELinux policy modules You shouldn't notice any change again. All modules should be migrated during selinux-policy update. Some of modules could be incompatible with the new policy so they'll need to be migrated manually. If they are part of any Fedora package, we will help with the migration. Just file a bug to a component and add us do CC field. We are ready to help with other modules or issues with migration on seli...@lists.fedoraproject.org mailing list. [1] https://fedoraproject.org/wiki/Changes/SELinuxPolicyStoreMigration Petr -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: SELinux policy store migration
On 06/12/2015 12:17 PM, Lennart Poettering wrote: On Thu, 11.06.15 06:51, Jan Kurik (jku...@redhat.com) wrote: = Proposed System Wide Change: SELinux policy store migration = https://fedoraproject.org/wiki/Changes/SELinuxPolicyStoreMigration I cannot make sense of this with my limited selinux knowledge, could you please elaborate on this on the changes page for people like me who only have a superficial understanding of selinux? Yeap, we are working on it. Basically the binary policy file (/etc/selinux/targeted/policy/policy.29) loaded to kernel is built from SELinux policy modules. These modules are currently located in /etc/selinux/targeted/modules and we call it as a module store. This store is now moved to /var/lib/selinux/targeted/modules. This only affects tools like semanage, semodule which are used for a policy manipulation. So we are able to boot without /var also from SELinux point of view. Thanks, Mirek For example: What is the policy store? Is that the compiled policy blob uploaded into the kernel? And if not, what is it? We support /var being split off and be mounted only very late at boot. Is that a problem for this proposal, and if not, why not? Does this require changes in systemd? Does this require changes anywhere in the core OS, outside of selinux' own userspace? And so on... Lennart -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F23 System Wide Change: SELinux policy store migration
On 06/11/2015 03:26 PM, Matthew Miller wrote: On Thu, Jun 11, 2015 at 06:51:52AM -0400, Jan Kurik wrote: In the SELinux userspace project release 2015-02-02, the SELinux policy store was moved from /etc/selinux/store/modules/ to /var/lib/selinux/store/. The change page notes performance improvements. Can these be quantified? At the very least, that kind of stuff is very useful for marketing. Yes, I agree it is very useful. It relates with CIL directly and it is a part of policy store migration change. There are data coming from SELinux Userspace upstream obtained on F20 and F21 policy. For example, we should do a better job for bugs like https://bugzilla.redhat.com/show_bug.cgi?id=1098446 I will attach an upstream discussion related to this topic. And of course we want to get real results/numbers once it is a part of rawhide by default. -- Miroslav Grepl Senior Software Engineer, SELinux Solutions Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: SELinux RPM scriplet issue annoucement
On 01/20/2014 06:48 PM, Adam Williamson wrote: On Mon, 2014-01-20 at 12:17 -0500, Matthew Miller wrote: On Sun, Jan 19, 2014 at 08:10:29PM +0100, Michael Schwendt wrote: A simple yum -y update ; reboot ; Oh, everything seems to work has not been enough this time. And it was an update with a screen full of ticket numbers for the included bug-fixes/changes. It could have broken something else, too. Once we have a better automation framework in place, we can have tests like: install selinux update, reboot, install (special) test package version 1, update to test package version 2. (In addition to a series of other things that should work with selinux enabled.) Btw, some other packages are in the same boat. Imagine a graphics driver update seems to work for three testers that are required for a +3 vote in the updates system, but fails badly for a hundred other users once it appears in the stable updates repo. That's a little harder, of course. So I've read through this thread now. A few notes: 1) The precise nature of the failure here makes it a tricky issue to deal with. We actually already know that this kind of 'delayed action' bug is a tricky scenario to deal with, because we already have a whole pretty well-known *category* of similar bugs: scriptlet errors themselves. As Harald has pointed out, scriptlet errors are very messy bugs that our current testing process is very poor at catching. If anyone's not familiar with the scriptlet error category, see https://fedoraproject.org/wiki/Common_F20_bugs#preun-fail . So while the idea of an SELinux-specific 'update it, then update it again' test case seems to make superficial sense, it's not actually an SELinux-specific test. We should in fact be doing this for *all* updates, or at the least, all updates that include any scriptlets. However, it's not even that simple, because this is something that makes much more sense to test in an automated way than manually - even more so than many things. This specific bug was a bit easier to test than the scriptlet case, because you just had to update *any other* package after updating selinux-policy to see the bug, but it's clearly in the same category as the more difficult case, and we should come up with an approach that handles them all. What looks like the right approach has already been suggested in the FESCo ticket on this: an automated test that takes the update, bumps the spec one revision and tries to update. So if the update is foo-1.1-2, the test would build a foo-1.1-3 package with no other changes, and try updating from 1.1-2 to 1.1-3. Doing this manually is of course a PITA and it's really a _very_ clear candidate for automation. Such a test would, I believe, have caught the bug. As posted to FESCo, though, it's still the case that we're working on the automation framework at present and the tests come after that. We are aiming to have the framework operational for the F21 cycle, AIUI, and it may be plausible to implement this test during that cycle. As such a test has several very desirable attributes - i.e. it catches bugs which: 1) cause serious problems that are difficult to recover from 2) we are currently very bad at catching manually 3) would be difficult and onerous to reliably catch manually even with improved manual testing procedures I'd suggest this test should be a high priority for implementation once taskotron is operational, perhaps equal in importance to re-implementing the current AutoQA tests. (Harald is probably correct to note that another bug of precisely this type might result in 'innocent' updates being 'blamed' for being broken, but we'd at least have a clear indication that something was seriously boned, and could investigate/clean up manually - the proposed automated test wouldn't make anything worse than it currently is). 1b) Just in case anyone had forgotten, though, we do have the infrastructure for creating package-specific test cases that get integrated with Bodhi to an extent, even though I don't think that's the way to go in this particular case: see https://fedoraproject.org/wiki/QA:SOP_package_test_plan_creation . 2) I already suggested to the SELinux devs on test@ that perhaps selinux-policy updates should have a higher autokarma threshold, and they agreed this might be a good idea. It would also be possible for them to disable autopush for selinux-policy updates and handle pushing them manually, based on whatever policy they choose, though of course that's more work than using autopush. 3) Someone noted that big selinux-policy updates are 'scary'. I think to be fair to the SELinux devs it's worth noting they push big updates all the time, with a very high success record. This is the first time I can recall a bug anywhere near this serious happening with an SELinux update to a stable release. AIUI, they have a very sensible policy for stable release updates, which is that except in very exceptional cases, updates can only make the policy *more
