Re: Trouble with install ordering and SELinux config
On 11/5/19 11:21 PM, Dridi Boukelmoune wrote: >> Hi, >> >> It looks like some leftover from the past. I don't really see why it >> should be there. >> >> This commit removes that: >> >> https://github.com/fedora-selinux/selinux-policy-macros/commit/5f366657da0c7c67f2448be03620581437c2dfbb >> >> Fixing it also in Rawhide and F31. > > Thanks a lot! Can it also happen for epel7 and 8? > > Pretty please :) > Please open bugzilla ticket. THanks, Lukas. > Dridi > -- Lukas Vrabec SELinux Evangelist, Senior Software Engineer, Security Technologies Red Hat, Inc. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Trouble with install ordering and SELinux config
ed.
>>>>> SELINUX=enforcing
>>>>> # SELINUXTYPE= can take one of these three values:
>>>>> # targeted - Targeted processes are protected,
>>>>> # minimum - Modification of targeted policy. Only selected
>>>>> processes are
>>>>> protected.
>>>>> # mls - Multi Level Security protection.
>>>>> SELINUXTYPE=targeted
>>>>>
>>>>> " > /etc/selinux/config
>>>>>
>>>>> ln -sf ../selinux/config /etc/sysconfig/selinux
>>>>> restorecon /etc/selinux/config 2> /dev/null || :
>>>>> else
>>>>> . /etc/selinux/config
>>>>> fi
>>>>> exit 0
>>>>>
>>>>> But can't this be achieved simply with:
>>>>>
>>>>> %config(noreplace) %{_sysconfdir}/selinux/config
>>>>>
>>>>> New installs would get the default config, but otherwise you would
>>>>> get a
>>>>> .rpmnew file.
>>>>>
>>>>> However, I realize that nothing is particularly simple about SELinux
>>>>> so there
>>>>> are probably things I'm not aware of that prevent this.
>>>>>
>>>>> PS - the else code seems to be a no-op.
>>>> Back when I was trying to find my own fixes, I managed to fix one
>>>> portion of the %post selinux that was enough to solve my own problems,
>>>> but this issue you're seeing is one that I wasn't able to find a fix
>>>> for myself. I've love to see a resolution to this.
>>>>
>>>> ___
>>>> devel mailing list --devel@lists.fedoraproject.org
>>>> To unsubscribe send an email todevel-le...@lists.fedoraproject.org
>>>> 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@lists.fedoraproject.org
>>>
>>>
>>>
>>> ___
>>> devel mailing list -- devel@lists.fedoraproject.org
>>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>> 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@lists.fedoraproject.org
>>>
>>
>>
>> --
>> Orion Poplawski
>> Manager of NWRA Technical Systems 720-772-5637
>> NWRA, Boulder/CoRA Office FAX: 303-415-9702
>> 3380 Mitchell Lane or...@nwra.com
>> Boulder, CO 80301 https://www.nwra.com/
>>
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>> 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@lists.fedoraproject.org
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
>
--
Lukas Vrabec
SELinux Evangelist,
Senior Software Engineer, Security Technologies
Red Hat, Inc.
signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
[SELinux] xdp_socket in Rawhide
Hi All, I created new selinux-policy build with support new class: xdp_socket https://koji.fedoraproject.org/koji/taskinfo?taskID=32331044 I don't expect any big troubles in rawhide, it passed my basic testing, but if you'll face any AVC where there will be class xdp_socket, please let me know ASAP. Thanks, Lukas. -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CVE-2018-14665 : Xorg X Server Vulnerabilities
On 11/2/18 7:01 AM, Raphael Groner wrote: >> On 11/1/18 5:08 PM, Cătălin George Feștilă wrote: >> >> SELinux can block the exploit if the "unconfined" module is disabled. > > Same thoughts here. No main process (by user) should be allowed to overwrite > system configuration except the dedicated tools or an editor. > >> I'm writing blog about it. When it will be ready, I add link also to >> this thread. > > Thanks. Please let us know about your work. > https://lukas-vrabec.com/index.php/2018/11/02/cve-2018-14665-xorg-x-server-vulnerabilities-vs-selinux/ > Regards, Raphael > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: CVE-2018-14665 : Xorg X Server Vulnerabilities
On 11/1/18 5:08 PM, Cătălin George Feștilă wrote: > Good to know. > I don't know all about of these problems (setuid and protect with > SELinux - can de an good idea ). > I used F28, I think also is not fixed with F29. > $ ls -l /usr/libexec/Xorg.wrap > -rwsr-xr-x. 1 root root 11376 Apr 23 2018 /usr/libexec/Xorg.wrap > SELinux can block the exploit if the "unconfined" module is disabled. I'm writing blog about it. When it will be ready, I add link also to this thread. Thanks, Lukas. > > On Thu, Nov 1, 2018 at 5:44 PM Chris Adams <mailto:li...@cmadams.net>> wrote: > > Once upon a time, Cătălin George Feștilă <mailto:catalinf...@gmail.com>> said: > > Thank you! > > > > On Thu, Nov 1, 2018 at 4:38 PM Reindl Harald > mailto:h.rei...@thelounge.net>> wrote: > > > > > > > > > > > Am 01.11.18 um 15:33 schrieb Cătălin George Feștilă: > > > > > https://www.securepatterns.com/2018/10/cve-2018-14665-xorg-x-server.html > > > > > > https://fedoraproject.org/wiki/Features/RemoveSETUID > > > Targeted release: Fedora 15 > > > > > > ls -la /usr/bin/Xorg > > > -rwxr-xr-x 1 root root 273 2018-04-23 20:16 /usr/bin/Xorg > > That means nothing... that's just a shell script that calls: > > $ ls -l /usr/libexec/Xorg.wrap > -rwsr-xr-x. 1 root root 11376 Apr 12 2018 /usr/libexec/Xorg.wrap > > which is where the problem lies. I think SELinux should help (because > it should stop writes to lots of things), but I haven't seen a bug or > statement from Fedora about vulnerability. > > -- > Chris Adams mailto:li...@cmadams.net>> > ___ > devel mailing list -- devel@lists.fedoraproject.org > <mailto:devel@lists.fedoraproject.org> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > <mailto:devel-le...@lists.fedoraproject.org> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [heads up] SELinux support for boltd service
Hi All, Adding builds with boltd SELinux support. Fedora 28: https://koji.fedoraproject.org/koji/buildinfo?buildID=1134436 Fedora Rawhide https://koji.fedoraproject.org/koji/buildinfo?buildID=1134361 SELinux denials please report here: https://bugzilla.redhat.com/show_bug.cgi?id=1607974 Thanks, Lukas. On 08/07/2018 11:19 AM, Lukas Vrabec wrote: > Hi, > > I saw several bugs where boltd daemon runs as unconfined_service_t. I > have prepared new SELinux module for it. > > I'll push it to Fedora Rawhide and also Fedora 28 soon. This module will > be in permissive mode, which means policy for boltd won't be enforced by > kernel, just AVCs will be logged even if the whole system will be in > Enforcing state. > > If you'll find some AVCs related to boltd, please use this bugzilla[1] > to report them. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1607974. > > Thanks, > Lukas. > -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LOA2NMOTAA25Y22OP2LS5IEPIZMVNOTV/
[heads up] SELinux support for boltd service
Hi, I saw several bugs where boltd daemon runs as unconfined_service_t. I have prepared new SELinux module for it. I'll push it to Fedora Rawhide and also Fedora 28 soon. This module will be in permissive mode, which means policy for boltd won't be enforced by kernel, just AVCs will be logged even if the whole system will be in Enforcing state. If you'll find some AVCs related to boltd, please use this bugzilla[1] to report them. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1607974. Thanks, Lukas. -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JRL5KVBNGTTBAK75VGT4FIVIUZDNLRDY/
Re: Heads up: selinux-policy-3.14.1-25.fc28 breaks GDM
On 05/24/2018 04:09 PM, Jerry James wrote: > On Thu, May 24, 2018 at 12:39 AM, Heiko Adams <m...@fedora-blog.de > <mailto:m...@fedora-blog.de>> wrote: > > I can't confirm that. Maybe because I relabel my system after every > selinux policy update. > > > As I said in the original message: > > "I did a full SELinux relabel immediately afterwards. Nothing > relevant changed labels." > > Now that I'm at work, I can confirm that my wimpy old work machine with > Intel graphics is not having any issues. The problem may be restricted > to systems using the Nvidia proprietary driver. Following build should fix this issue: https://koji.fedoraproject.org/koji/buildinfo?buildID=1084439 Thanks. Lukas. > -- > Jerry James > http://www.jamezone.org/ > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/M2FHUCS3YBQQQCBQKS7BXTXIAZHR2B54/ > -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/73PCEZV4B5A4AKUDLZGXMKO5RASAPLJX/
Re: SELinux Policy Modules Packaging Draft
On 04/27/2018 10:23 AM, Pavel Raiskup wrote: > Hi all, any plan to ratify the Draft? [1] > > I'm thinking whether it is good time already to add '*-selinux' subpackage > to generally selinux-covered services (by selinux-policy-targeted), like > e.g. 'httpd' or 'postgresql-server'. > > Any experiences? > > [1] > https://fedoraproject.org/w/index.php?title=Talk:SELinux_Policy_Modules_Packaging_Draft > > Thanks, > Pavel > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Hi Pavel, I'm in touch with packaging committee, to include following Draft[2] to official rpm package guidelines. Here is the thread about it [3]. If you would like to have ship own SELinux policy, please follow these guidelines[2]. [2] https://fedoraproject.org/wiki/PackagingDrafts/SELinux_Independent_Policy [3] https://pagure.io/packaging-committee/issue/726 Lukas. -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: wrong selinux label on user-1000.journal, AVC denials
On 12/16/2017 12:04 AM, Chris Murphy wrote:
Fedora 27 workstation. I'm getting selinux AVC denial messages in the
journal as a result of user-1000.journal having label
system_u:object_r:unlabeled_t:s0. It's the only log file with that
label, the other files and the directory its in have
system_u:object_r:var_log_t:s0.
The AVC message of course go away if I relabel /var/log/journal but
then maybe two weeks later the problem starts happening again when the
log gets rotated. For whatever reason this is not happening with the
system.journal.
Dec 15 15:54:47 f27h.localdomain audit[640]: AVC avc: denied { read
write } for pid=640 comm="systemd-journal" name="user-1000.journal"
dev="nvme0n1p9" ino=1174 scontext=system_u:system_r:syslogd_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0
Is this a systemd or selinux-policy bug? Or other?
Michal, what you think about this?
How is the user-100.journal file created? It's end up as unlabeled_t so
some actions during early state of booting system?
Thanks,
Lukas.
--
Lukas Vrabec
Software Engineer, Security Technologies
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 11/23/2017 10:17 AM, Javier Martinez Canillas wrote: Hello, On Fri, Oct 20, 2017 at 2:12 PM, Lukas Vrabec <lvra...@redhat.com> wrote: [snip] Hello community, We, as Red Hat SELinux team, apologise for recent delays with our answers to your requests and questions related to SELinux. We have been quite busy last couple of weeks so we decided to set a lower priority for Fedora work. We already responded and resolved what was needed and we are ready to react more flexibly in the future. Note: If you are interested in writing custom SELinux policy for your package, you can follow the https://fedoraproject.org/wiki/SELinux/IndependentPolicy documentation on wiki. To update the tpm2-abrmd [0] package to the latest version, I need to add a SELinux policy due recent upstream changes in the upstream project. But after reading the documents referred in this thread, is still not clear to me if the preferred method nowadays is to propose adding the SELinux policy to the system wide selinux-policy package or to ship a custom SELinux security module for the package. Hi, SELinux policy for this project is already existing? If not I can help you with creating policy for this project. From SELinux team it's prefered to add policy to your package. Guidelines how to do that is in progress to be part of rpm packaging guidelines. Lukas. Regards, Lukas [0]: https://github.com/intel/tpm2-abrmd Best regards, Javier ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 10/21/2017 08:48 PM, Kevin Fenzi wrote: On 10/20/2017 05:12 AM, Lukas Vrabec wrote: Hello community, Hey Lukas. Thanks for chiming in here. We, as Red Hat SELinux team, apologise for recent delays with our answers to your requests and questions related to SELinux. We have been quite busy last couple of weeks so we decided to set a lower priority for Fedora work. We already responded and resolved what was needed and we are ready to react more flexibly in the future. Perhaps you could outline the best ways for people to contribute/get attention? bugzilla bugs? github issues? PR's? Also, perhaps it would make sense to move to a more normal looking release flow instead of a massive patch? I think that might make it easier to see whats going on and how to contribute. This "massive" patch is here because, we diverted from Upsteam policy. Because Upstream policy is much more strict, you cannot even boot F26+ just with upstream policy. We confine more services then upstream and we're more benevolent. This should change, and we're trying to focus on technical solution which should decrease amount of maintenance of selinux-policy. We'll inform you about this project. Note: If you are interested in writing custom SELinux policy for your package, you can follow the https://fedoraproject.org/wiki/SELinux/IndependentPolicy documentation on wiki. Perhaps you could submit this to the FPC and get it reviewed and moved under the normal packaging space? Will do. Lukas. Thanks again, kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 10/13/2017 11:07 PM, Jerry James wrote: On Sat, Oct 7, 2017 at 9:34 AM, Jerry James <loganje...@gmail.com> wrote: I don't believe that anybody looks at those pull requests on a regular basis. Should somebody be doing so? There are 8 pull requests, dating back to about the time of the above conversation. Five of those don't contain a single comment. I opened one for gcl on July 29, and added a comment a month later asking if somebody was going to look at it. No response. This is a bit annoying, considering that I opened a bugzilla request asking for the same thing 4 years ago, and no action has ever been taken on it. I thought maybe a PR would finally get something to happen. Nearly a week has gone by, and no answer. I'm really stumped about what to do. Let me summarize the whole long saga and solicit help. GCL is a Common Lisp implementation. It is known for its speed compared to other CL implementations. It has a long lineage, summarized here: https://en.wikipedia.org/wiki/GNU_Common_Lisp. I took over maintenance of the package in late 2008 when the previous maintainer did not have time to continue. At that point, the package did not build in Rawhide and was slated to be dropped from Fedora soon. I got it working with help from upstream and Daniel Walsh, who provided advice on putting together an SELinux policy to account for the fact that GCL produces executable code on the fly by calling mprotect on selected pages. Fast forward to 2013. By that time, the GCL policy also had to mention maxima executables, since executables built with GCL also use the GCL memory allocator. I figured that meant it was time to merge the GCL policy into the system policy, and consequently opened a bugzilla ticket. In spite of me trying to reboot the conversation a couple of times, those involved who held the SELinux reins for Fedora, Just. Could. Not. Stay. On. Topic. We talked about the execheap permission in general, and its place in the universe. Some of them sneeringly, condescendingly wondered why upstream and I were both so incompetent that we didn't just rewrite the allocator to use mmap. (Hint: it isn't easy, and upstream isn't interested in the exercise.) After multiple failures on my part to get something to happen, I gave up in despair. Fast forward to 2017. Attempts to build maxima with gcl on aarch64 started hanging at package install time. See https://bugzilla.redhat.com/show_bug.cgi?id=1435395. This was blamed on gcl, incorrectly I believe. As I pointed out in the bug, nothing built from gcl sources runs at package install time, so the hang must be happening inside one of fixfiles, semodule, or restorecon, which ARE run from the gcl install scripts because GCL has to install its own SELinux policy, due to that policy not being merged into the system policy. So, policycoreutils maintainers! Something Is Afoot on aarch64! But that's not the end of the fun. GCL failed the mass rebuild this summer. It built successfully on every architecture but s390x. On s390x, the build failed due to a failed call to mprotect(), almost certainly a sign that SELinux was in enforcing mode on the builder. Was that a known issue with s390x builders? And, if so, has it been rectified since? If so, I'll try building again. I still want the system policy to account for GCL, in some way or another. But, as you can see from the quoted text above, submitting a pull request to the relevant git repository has resulted in months of . And pointing that out on this list last weekend has resulted in still more of the crickets. So ... what is a packager supposed to do Why is it so hard to get any attention for submissions to the system SELinux policy? There should be a barrier to entry; I understand that. But I can't even get the gatekeeper to have a conversation with me. Hellp!!! Frustratedly yours, Hello community, We, as Red Hat SELinux team, apologise for recent delays with our answers to your requests and questions related to SELinux. We have been quite busy last couple of weeks so we decided to set a lower priority for Fedora work. We already responded and resolved what was needed and we are ready to react more flexibly in the future. Note: If you are interested in writing custom SELinux policy for your package, you can follow the https://fedoraproject.org/wiki/SELinux/IndependentPolicy documentation on wiki. Regards, Lukas -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] Default value of SELinux boolean httpd_graceful_shutdown will changed.
On 09/29/2017 03:30 PM, Lukas Vrabec wrote: I'm planning change the default value of httpd_graceful_shutdown boolean in Fedora Rawhide because of improving SELinux configuration. Rawhide builds with this change will be available in ~5 days. Together with Dan Walsh, we agreed on that httpd_graceful_shutdown boolean should be by default turned off. This boolean allows HTTPD to connect to port 80 for graceful shutdown, but it's breaking the functionality of another boolean called: httpd_can_network_connect. This boolean allows HTTPD scripts and modules to connect to the network using TCP and it's turned off by default. Turning this boolean off can cause some troubles, on web-servers where processes with httpd_t SELinux domain connecting to tcp ports: 80, 81, 443, 488, 8008, 8009, 8443, 9000 If you would like to turn in on again, use semanage command: # semanage boolean -m --on httpd_graceful_shutdown If you have any questions, feel free to contact me. Lukas. Hi, This change is already in Fedora Rawhide. I had discussion with Dan Walsh and Joe Orton (apache maintainer) about this and I would be great have it also in Fedora 27. Users, upgrading from F26 to F27 won't be affected (we change only default value of boolean not a actual value), but fresh installs will be affected. Apache in default configuration doesn't need this boolean anymore and as I said above, this is big security improvement. Is it somehow possible to push it into F27 ? Thanks, Lukas. -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] Default value of SELinux boolean httpd_graceful_shutdown will changed.
On 09/29/2017 03:30 PM, Lukas Vrabec wrote: I'm planning change the default value of httpd_graceful_shutdown boolean in Fedora Rawhide because of improving SELinux configuration. Rawhide builds with this change will be available in ~5 days. Together with Dan Walsh, we agreed on that httpd_graceful_shutdown boolean should be by default turned off. This boolean allows HTTPD to connect to port 80 for graceful shutdown, but it's breaking the functionality of another boolean called: httpd_can_network_connect. This boolean allows HTTPD scripts and modules to connect to the network using TCP and it's turned off by default. Turning this boolean off can cause some troubles, on web-servers where processes with httpd_t SELinux domain connecting to tcp ports: 80, 81, 443, 488, 8008, 8009, 8443, 9000 If you would like to turn in on again, use semanage command: # semanage boolean -m --on httpd_graceful_shutdown If you have any questions, feel free to contact me. Lukas. Build selinux-policy-3.13.1-291.fc28 was completed in koji. This build contains also changed default value of httpd_graceful_shutdown boolean. Lukas. -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] Default value of SELinux boolean httpd_graceful_shutdown will changed.
On 09/29/2017 04:39 PM, Alexander Bokovoy wrote: On pe, 29 syys 2017, Lukas Vrabec wrote: On 09/29/2017 03:57 PM, Alexander Bokovoy wrote: On pe, 29 syys 2017, Lukas Vrabec wrote: I'm planning change the default value of httpd_graceful_shutdown boolean in Fedora Rawhide because of improving SELinux configuration. Rawhide builds with this change will be available in ~5 days. Together with Dan Walsh, we agreed on that httpd_graceful_shutdown boolean should be by default turned off. This boolean allows HTTPD to connect to port 80 for graceful shutdown, but it's breaking the functionality of another boolean called: httpd_can_network_connect. This boolean allows HTTPD scripts and modules to connect to the network using TCP and it's turned off by default. Turning this boolean off can cause some troubles, on web-servers where processes with httpd_t SELinux domain connecting to tcp ports: 80, 81, 443, 488, 8008, 8009, 8443, 9000 If you would like to turn in on again, use semanage command: # semanage boolean -m --on httpd_graceful_shutdown In FreeIPA we have httpd_can_network_connect enabled. I just checked a F26 system and I have both booleans enabled. # getsebool -a|egrep 'httpd_graceful_shutdown|httpd_can_network_connect ' httpd_can_network_connect --> on httpd_graceful_shutdown --> on So I'm a bit confused: disabling httpd_graceful_shutdown will have or wouldn't have an effect on httpd_can_network_connect being enabled? httpd_graceful_shutdown is subset of httpd_can_network_connect. Turning on httpd_graceful_shutdown you allow httpd_t domain connecting just to ports labeled as httpd_port_t. Turning on httpd_can_network_connect you allow httpd_t domain connecting to all ports from SELinux POV. Right now, we ship selinux-policy with httpd_graceful_shutdown turned on and httpd_can_network_connect turned off. But it's confusing for users because they have httpd_can_connect turned off but httpd_t domain can still connect co http_port_t ports becuase of httpd_gracefull_shudown. I hope it's more clear now. Yes, thanks. We need to use httpd_can_connect because we need to connect to ports that chosen randomly by a remote side thanks to a port-mapping feature of DCE RPC protocol stack. In that case you are using httpd_can_network_connect correctly. Lukas. -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: [HEADS UP] Default value of SELinux boolean httpd_graceful_shutdown will changed.
On 09/29/2017 03:57 PM, Alexander Bokovoy wrote: On pe, 29 syys 2017, Lukas Vrabec wrote: I'm planning change the default value of httpd_graceful_shutdown boolean in Fedora Rawhide because of improving SELinux configuration. Rawhide builds with this change will be available in ~5 days. Together with Dan Walsh, we agreed on that httpd_graceful_shutdown boolean should be by default turned off. This boolean allows HTTPD to connect to port 80 for graceful shutdown, but it's breaking the functionality of another boolean called: httpd_can_network_connect. This boolean allows HTTPD scripts and modules to connect to the network using TCP and it's turned off by default. Turning this boolean off can cause some troubles, on web-servers where processes with httpd_t SELinux domain connecting to tcp ports: 80, 81, 443, 488, 8008, 8009, 8443, 9000 If you would like to turn in on again, use semanage command: # semanage boolean -m --on httpd_graceful_shutdown In FreeIPA we have httpd_can_network_connect enabled. I just checked a F26 system and I have both booleans enabled. # getsebool -a|egrep 'httpd_graceful_shutdown|httpd_can_network_connect ' httpd_can_network_connect --> on httpd_graceful_shutdown --> on So I'm a bit confused: disabling httpd_graceful_shutdown will have or wouldn't have an effect on httpd_can_network_connect being enabled? httpd_graceful_shutdown is subset of httpd_can_network_connect. Turning on httpd_graceful_shutdown you allow httpd_t domain connecting just to ports labeled as httpd_port_t. Turning on httpd_can_network_connect you allow httpd_t domain connecting to all ports from SELinux POV. Right now, we ship selinux-policy with httpd_graceful_shutdown turned on and httpd_can_network_connect turned off. But it's confusing for users because they have httpd_can_connect turned off but httpd_t domain can still connect co http_port_t ports becuase of httpd_gracefull_shudown. I hope it's more clear now. Do I need to do anything in FreeIPA setup? No if httpd_can_network_connect is enabled during FreeIPA setup, you don't need to change anything. Lukas. -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[HEADS UP] Default value of SELinux boolean httpd_graceful_shutdown will changed.
I'm planning change the default value of httpd_graceful_shutdown boolean in Fedora Rawhide because of improving SELinux configuration. Rawhide builds with this change will be available in ~5 days. Together with Dan Walsh, we agreed on that httpd_graceful_shutdown boolean should be by default turned off. This boolean allows HTTPD to connect to port 80 for graceful shutdown, but it's breaking the functionality of another boolean called: httpd_can_network_connect. This boolean allows HTTPD scripts and modules to connect to the network using TCP and it's turned off by default. Turning this boolean off can cause some troubles, on web-servers where processes with httpd_t SELinux domain connecting to tcp ports: 80, 81, 443, 488, 8008, 8009, 8443, 9000 If you would like to turn in on again, use semanage command: # semanage boolean -m --on httpd_graceful_shutdown If you have any questions, feel free to contact me. Lukas. -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
[HEADS UP] Removing unnecessary dac_override capability in SELinux modules
Hi Everybody, I'll push builds with updated SELinux security policy into Rawhide soon, this build will remove unnecessary dac_override capability in domains where it's not needed. Because of this change, we're able to remove a lot of unnecessary rules allowing dac_override, which means tightened security in whole Fedora from SELinux POV. This change will be part of build: selinux-policy-3.13.1-288.fc28.noarch Tracker bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=1494520 This may result in some AVCs related to missing DAC_OVERRIDE capability. Feel free to create a bugzilla or add AVCs to this issue on github: https://github.com/fedora-selinux/selinux-policy/issues/200 I'll be lurking around fedora rawhide bugs very often and I'm ready to fix all these bugs asap also with new builds. Feel free to use selinux-policy nightly builds to get fixes ASAP: https://copr.fedorainfracloud.org/coprs/lvrabec/selinux-policy-nightly/ Thanks, Lukas. -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Many 'map' SELinux denials in current Rawhide
On 08/15/2017 05:25 PM, Adam Williamson wrote: On Tue, 2017-08-15 at 16:58 +0200, Lukas Vrabec wrote: On 08/15/2017 01:37 AM, Adam Williamson wrote: Hi folks! Just wanted to give a heads-up on this: it seems that a recent selinux- policy update, 3.13.1-269 , introduced a new permission called 'map'. This seems to have resulted in rather a large amount of new SELinux denials for this permission in various cases. Some are fairly serious - e.g. there's a denial for the systemd journal - and in some cases seem to prevent systems from booting correctly at all. I've created a tracker bug for now: https://bugzilla.redhat.com/show_bug.cgi?id=1481454 and intend to mark all the 'map' bugs I find as blocking that tracker. Petr, Lukas, it'd be great if we could get as many of these cleaned up as fast as possible; it's been hard to get a decent evaluation of Rawhide's current state for quite a while, now, due to various problems, and now *this* problem is making things difficult too. Of course, for day-to-day Rawhide users, booting with 'enforcing=0' can work around these issues for now (or you could, I suppose, create a local policy that just blanket allowed the 'map' permission in all cases, so all other SELinux restrictions would remain in place). Thanks! Hi Adam, I fixed all BZs from tracker bug. selinux-policy build is in koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=21243824 Thanks a lot, we'll see how the next compose goes. Okay, Please let me know ASAP if there will be more issues. Thanks, Lukas. -- Lukas Vrabec SELinux Solutions Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Re: Many 'map' SELinux denials in current Rawhide
On 08/15/2017 04:58 PM, Lukas Vrabec wrote: On 08/15/2017 01:37 AM, Adam Williamson wrote: Hi folks! Just wanted to give a heads-up on this: it seems that a recent selinux- policy update, 3.13.1-269 , introduced a new permission called 'map'. This seems to have resulted in rather a large amount of new SELinux denials for this permission in various cases. Some are fairly serious - e.g. there's a denial for the systemd journal - and in some cases seem to prevent systems from booting correctly at all. I've created a tracker bug for now: https://bugzilla.redhat.com/show_bug.cgi?id=1481454 and intend to mark all the 'map' bugs I find as blocking that tracker. Petr, Lukas, it'd be great if we could get as many of these cleaned up as fast as possible; it's been hard to get a decent evaluation of Rawhide's current state for quite a while, now, due to various problems, and now *this* problem is making things difficult too. Of course, for day-to-day Rawhide users, booting with 'enforcing=0' can work around these issues for now (or you could, I suppose, create a local policy that just blanket allowed the 'map' permission in all cases, so all other SELinux restrictions would remain in place). Thanks! Hi Adam, I fixed all BZs from tracker bug. selinux-policy build is in koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=21243824 Lukas. -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Many 'map' SELinux denials in current Rawhide
On 08/15/2017 01:37 AM, Adam Williamson wrote: Hi folks! Just wanted to give a heads-up on this: it seems that a recent selinux- policy update, 3.13.1-269 , introduced a new permission called 'map'. This seems to have resulted in rather a large amount of new SELinux denials for this permission in various cases. Some are fairly serious - e.g. there's a denial for the systemd journal - and in some cases seem to prevent systems from booting correctly at all. I've created a tracker bug for now: https://bugzilla.redhat.com/show_bug.cgi?id=1481454 and intend to mark all the 'map' bugs I find as blocking that tracker. Petr, Lukas, it'd be great if we could get as many of these cleaned up as fast as possible; it's been hard to get a decent evaluation of Rawhide's current state for quite a while, now, due to various problems, and now *this* problem is making things difficult too. Of course, for day-to-day Rawhide users, booting with 'enforcing=0' can work around these issues for now (or you could, I suppose, create a local policy that just blanket allowed the 'map' permission in all cases, so all other SELinux restrictions would remain in place). Thanks! Hi Adam, I fixed all BZs from tracker bug. selinux-policy build is in koji: https://koji.fedoraproject.org/koji/taskinfo?taskID=21243824 Lukas. -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: SELinux policy contibutions
On 03/23/2017 01:12 PM, Robert Marcano wrote: Greetings. Is https://github.com/fedora-selinux/selinux-policy-contrib the right place to contribute to the Fedora SELinux policy? I added a pull request for a small update needed for a new release of cups-pdf, but I am not sure someone is monitoring that. There is another one from rhatdan there so I presume is the right place. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Yes, It's right place. I'll check tour PR ASAP. Lukas. -- Lukas Vrabec SELinux Solutions Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: Adding SELinux Policy to a (Private) Package
Hi John, This[0] is tutorial how to create custom policy RPM package. [0] http://lvrabec-selinux.rhcloud.com/2015/07/07/how-to-create-selinux-product-policy/ If you have any questions, feel free to contact me. Thank you. On 02/24/2016 06:06 PM, John Florian wrote: Is this[0] really the latest greatest documentation for doing this? Given that it references FC5 it seems rather dated and I wouldn’t expect something like this to still be in Draft. [0] https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft -- John Florian -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- Lukas Vrabec SELinux Solutions Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
