Re: I want to turn on a part of the kernel to make SELinux checking more stringent.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/26/2014 03:49 PM, Andrew Lutomirski wrote: On Sun, Jan 26, 2014 at 12:38 PM, Richard W.M. Jones rjo...@redhat.com wrote: Slightly OT, but is SELinux stopping programs from executing code at address zero? (And how can I stop it doing that?) JONESFORTH, a public domain FORTH I wrote, is written in x86 assembler and prefers to put its threaded interpreter at address 0. This worked fine before, but has now stopped working, and this is reported to be due to SELinux. IIRC, in new kernels, /proc/sys/vm/mmap_min_addr and MAC policy both have to allow the mmap call. In older kernels, only one of them had to allow it. Maybe some day SMAP-capable machines (e.g. Haswell, I think) will ignore these settings entirely -- I think that SMAP covers all the cases that mmap_min_addr was meant to pretect against. --Andy setsebool -P mmap_low_allowed 1 Will turn off this protection from an SELinux point of view, although you should be careful with this. http://rwmj.wordpress.com/2010/08/07/jonesforth-git-repository/#comment-6591 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLmfwEACgkQrlYvE4MpobOECwCfVZ5Q7fMjcYQQ/KHRZF2krmq3 07EAn0BUTIuX/i3WtlEd3MBaMXqpj5Xl =dnIj -END PGP SIGNATURE- -- 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/24/2014 07:29 PM, Alek Paunov wrote: On 24.01.2014 21:20, Daniel J Walsh wrote: No, we pretty much allow executable stack/memory from user processes now and block it for most daemons, except for those that need it. My understanding of this change is that the kernel was not doing complete checking, but most apps at this point do the right thing. We will turn it on in Rawhide and through the beta. If we see problems we will revert. It is now a one line change in SELinux newbie question: Where the daemons exception is actually defined. My practical interest is: What should be added to LuaJIT [1] to be able to run e.g. non-packaged web servers like [2]? Thanks, Alek [1] http://pkgs.fedoraproject.org/cgit/luajit.git/plain/luajit.spec [2] https://github.com/kernelsauce/turbo I don't really understand your question. When you run your Web Server does SELinux actually block anything? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLmf1EACgkQrlYvE4MpobMNAQCeKcLabW047Plzf6MDdXUIfBEk uBMAn3Oq2ZBEnvDQcKLdV8u/iKEz3CTu =mdtX -END PGP SIGNATURE- -- 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
On Fri, Jan 24, 2014 at 04:32:54PM +0100, Lennart Poettering wrote:
Do we really need a service for this? Can't this be done instead via a
tmpfiles snippet that uses f and the extra argument at the end?
I mean I am not convinced it's worth involving shell here. Also the
canonical way to write things to /proc or /sys is
{/etc,/usr/lib/}/sysctl.d/ and {/etc,/usr/lib/}/tmpfiles.d/ if it's
simple and static. And I don't see why we shouldn't do this differently
in this case than in all others...
Using tmpfiles.d for this is not very obvious. Who would expect that a
service intended to handle temporary files is used for configuration?
For example the man page says:
| tmpfiles.d — Configuration for creation, deletion and cleaning of
| volatile and temporary files
Regards
Till
--
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: I want to turn on a part of the kernel to make SELinux checking more stringent.
Slightly OT, but is SELinux stopping programs from executing code at address zero? (And how can I stop it doing that?) JONESFORTH, a public domain FORTH I wrote, is written in x86 assembler and prefers to put its threaded interpreter at address 0. This worked fine before, but has now stopped working, and this is reported to be due to SELinux. http://rwmj.wordpress.com/2010/08/07/jonesforth-git-repository/#comment-6591 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
On Sun, Jan 26, 2014 at 12:38 PM, Richard W.M. Jones rjo...@redhat.com wrote: Slightly OT, but is SELinux stopping programs from executing code at address zero? (And how can I stop it doing that?) JONESFORTH, a public domain FORTH I wrote, is written in x86 assembler and prefers to put its threaded interpreter at address 0. This worked fine before, but has now stopped working, and this is reported to be due to SELinux. IIRC, in new kernels, /proc/sys/vm/mmap_min_addr and MAC policy both have to allow the mmap call. In older kernels, only one of them had to allow it. Maybe some day SMAP-capable machines (e.g. Haswell, I think) will ignore these settings entirely -- I think that SMAP covers all the cases that mmap_min_addr was meant to pretect against. --Andy http://rwmj.wordpress.com/2010/08/07/jonesforth-git-repository/#comment-6591 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
On Sun, Jan 26, 2014 at 9:38 PM, Richard W.M. Jones rjo...@redhat.com wrote: Slightly OT, but is SELinux stopping programs from executing code at address zero? (And how can I stop it doing that?) JONESFORTH, a public domain FORTH I wrote, is written in x86 assembler and prefers to put its threaded interpreter at address 0. This worked fine before, but has now stopped working, and this is reported to be due to SELinux. http://rwmj.wordpress.com/2010/08/07/jonesforth-git-repository/#comment-6591 Maybe you just need to set /proc/sys/vm/mmap_min_addr to 0 ? But that's a bad idea as it makes kernel bugs (null pointer deference) easy to exploit. -- 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
On Sun, Jan 26, 2014 at 08:38:25PM +, Richard W.M. Jones wrote: JONESFORTH, a public domain FORTH I wrote, is written in x86 assembler and prefers to put its threaded interpreter at address 0. Can you change its preference? Permitting the mapping of executable code at address 0 makes it much easier to exploit null pointer vulnerabilities in the kernel. Recent (within the past few years…) kernels will refuse to let you mmap stuff below 64K or so regardless of selinux policy, so this may break on other distributions as well. -- Matthew Garrett | mj...@srcf.ucam.org -- 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
Just replying to the subject, without going into the implementation details: We've just hit two critical regressions, one in Fedora 20 (see the 2+ threads about it) and one in Rawhide (https://bugzilla.redhat.com/show_bug.cgi?id=1052317, still open!), as a result of SELinux checking being TOO stringent, and you want to make it even MORE stringent??? Big -1! It's time to stop the madness and just disable SELinux altogether by default! Kevin Kofler -- 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
On Fri, 24.01.14 10:22, Daniel J Walsh (dwa...@redhat.com) wrote:
Heya,
Do we really need a service for this? Can't this be done instead via a
tmpfiles snippet that uses f and the extra argument at the end?
I mean I am not convinced it's worth involving shell here. Also the
canonical way to write things to /proc or /sys is
{/etc,/usr/lib/}/sysctl.d/ and {/etc,/usr/lib/}/tmpfiles.d/ if it's
simple and static. And I don't see why we shouldn't do this differently
in this case than in all others...
If you would ship a simple tmpfiles snippet in /usr/lib/tmpfiles.d/,
then users who want to opt out of this could simply symlink the file to
/dev/null in /etc/tmpfiles.d/.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wrote a systemd unit file to enable it, and to allow a user to disable the
feature if he wants.
# cat /usr/lib/systemd/system/selinux-checkreqprot.service
[Unit]
Description=SELinux check actual protection flags applied by kernel, rather
than checking what application requested.
[Service]
Type=oneshot
RemainAfterExit=yes
Environment=CHECKREQPROT=0
EnvironmentFile=-/etc/selinux/config
ExecStart=/bin/sh -c '/bin/echo $CHECKREQPROT /sys/fs/selinux/checkreqprot'
I would like to enable this service on the post install of a initial install
of libselinux. But I believe this will not happen with
%systemd_post_enable selinux-checkreqprot.service
How would I go about doing this?
I know there is one problem in the unit file, it will fail if
/sys/fs/selinux/checkreqprot, does not exist. Is their an easy check to just
exit if this file does not exist?
Also is using a unit file for this, the best way to handle this?
Lennart
--
Lennart Poettering, Red Hat
--
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: I want to turn on a part of the kernel to make SELinux checking more stringent.
On Fri, 24 Jan 2014, Daniel J Walsh wrote: I wrote a systemd unit file to enable it, and to allow a user to disable the feature if he wants. # cat /usr/lib/systemd/system/selinux-checkreqprot.service [Unit] Description=SELinux check actual protection flags applied by kernel, rather than checking what application requested. What does this actually do/mean? (Sorry if it's obvious, it isn't to me!) -- Benjamin Lewis -- 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
On Fri, Jan 24, 2014 at 10:22:56AM -0500, Daniel J Walsh wrote:
ExecStart=/bin/sh -c '/bin/echo $CHECKREQPROT /sys/fs/selinux/checkreqprot'
ExecStart=/bin/sh -c '/bin/echo ${CHECKREQPROT} /sys/fs/selinux/checkreqprot'
I think we really need an echo command with sudo syntax. I keep a local
script which does that, called fecho. The syntax is 'fecho [-a] arg... file',
where -a means append. Maybe something like this could be added to util-linux
or somewhere.
Zbyszek
--
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: I want to turn on a part of the kernel to make SELinux checking more stringent.
On 01/24/2014 03:44 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Jan 24, 2014 at 10:22:56AM -0500, Daniel J Walsh wrote:
ExecStart=/bin/sh -c '/bin/echo $CHECKREQPROT /sys/fs/selinux/checkreqprot'
ExecStart=/bin/sh -c '/bin/echo ${CHECKREQPROT} /sys/fs/selinux/checkreqprot'
I think we really need an echo command with sudo syntax. I keep a local
script which does that, called fecho. The syntax is 'fecho [-a] arg... file',
where -a means append. Maybe something like this could be added to util-linux
or somewhere.
Zbyszek
When we started the migration of units, using ExecStart=/bin/sh -c was
generally frown upon since unit files aren't shell scripts and weren't
supposed to be used as such, has this changed?
JBG
--
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: I want to turn on a part of the kernel to make SELinux checking more stringent.
Daniel J Walsh (dwa...@redhat.com) said: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I wrote a systemd unit file to enable it, and to allow a user to disable the feature if he wants. ... why is this not a sysctl? Bill -- 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/24/2014 10:32 AM, Lennart Poettering wrote:
On Fri, 24.01.14 10:22, Daniel J Walsh (dwa...@redhat.com) wrote:
Heya,
Do we really need a service for this? Can't this be done instead via a
tmpfiles snippet that uses f and the extra argument at the end?
No I did not know that tmpfiles.d did this. I will look into using that.
I mean I am not convinced it's worth involving shell here. Also the
canonical way to write things to /proc or /sys is
{/etc,/usr/lib/}/sysctl.d/ and {/etc,/usr/lib/}/tmpfiles.d/ if it's simple
and static. And I don't see why we shouldn't do this differently in this
case than in all others...
If you would ship a simple tmpfiles snippet in /usr/lib/tmpfiles.d/, then
users who want to opt out of this could simply symlink the file to
/dev/null in /etc/tmpfiles.d/.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1
I wrote a systemd unit file to enable it, and to allow a user to disable
the feature if he wants.
# cat /usr/lib/systemd/system/selinux-checkreqprot.service [Unit]
Description=SELinux check actual protection flags applied by kernel,
rather than checking what application requested.
[Service] Type=oneshot RemainAfterExit=yes Environment=CHECKREQPROT=0
EnvironmentFile=-/etc/selinux/config ExecStart=/bin/sh -c '/bin/echo
$CHECKREQPROT /sys/fs/selinux/checkreqprot'
I would like to enable this service on the post install of a initial
install of libselinux. But I believe this will not happen with
%systemd_post_enable selinux-checkreqprot.service
How would I go about doing this?
I know there is one problem in the unit file, it will fail if
/sys/fs/selinux/checkreqprot, does not exist. Is their an easy check to
just exit if this file does not exist?
Also is using a unit file for this, the best way to handle this?
Lennart
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlLijEAACgkQrlYvE4MpobMm5gCfebHFEnypgZbZy0fVSR1Omz0I
0N8An3c4B9rP8hpV0Jkla8bQIXATzpT4
=KUxo
-END PGP SIGNATURE-
--
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: I want to turn on a part of the kernel to make SELinux checking more stringent.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is the request from upstream to enable this feature in Rawhide, with an explanation of what it does. Android is starting to apply execmem and friends to the non-Dalvik components (i.e. non-Java components, primarily the native system daemons). As part of that, I uploaded a change to effectively echo 0 /sys/fs/selinux/checkreqprot so that we always check the actual protection flags applied by the kernel rather than only checking what the application requested. Originally checkreqprot was to support legacy applications that had no PT_GNU_STACK marking or were marked with PT_GNU_STACK RWE, so that we wouldn't have to add execute permission pervasively to policy for such applications. But it effectively provides a way to bypass policy by creating such an application, and as I later discovered, just by calling personality(READ_IMPLIES_EXEC) from an application at any time. The simplest way to eliminate that bypass comprehensively is to change the defaults for checkreqprot. I think this is likely safe in Fedora since you now allow execmem by default to most domains. Can we get the same change applied in Fedora, either by changing the default kernel configuration (CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=0) or by putting something in an init script to set the /sys/fs/selinux/checkreqprot value? -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLijmYACgkQrlYvE4MpobP3GgCg0sGEjAuD7tKM+4aH3HkGOnJP wuYAoJOfrvEjYm90uwUMpDIW0p7NfSel =DOlV -END PGP SIGNATURE- -- 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
On Fri, Jan 24, 2014 at 8:01 AM, Daniel J Walsh dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here is the request from upstream to enable this feature in Rawhide, with an explanation of what it does. Android is starting to apply execmem and friends to the non-Dalvik components (i.e. non-Java components, primarily the native system daemons). As part of that, I uploaded a change to effectively echo 0 /sys/fs/selinux/checkreqprot so that we always check the actual protection flags applied by the kernel rather than only checking what the application requested. Originally checkreqprot was to support legacy applications that had no PT_GNU_STACK marking or were marked with PT_GNU_STACK RWE, so that we wouldn't have to add execute permission pervasively to policy for such applications. But it effectively provides a way to bypass policy by creating such an application, and as I later discovered, just by calling personality(READ_IMPLIES_EXEC) from an application at any time. The simplest way to eliminate that bypass comprehensively is to change the defaults for checkreqprot. I think this is likely safe in Fedora since you now allow execmem by default to most domains. Can we get the same change applied in Fedora, either by changing the default kernel configuration (CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=0) or by putting something in an init script to set the /sys/fs/selinux/checkreqprot value? I admit that I'm extremely late to the party (if I could go back in time, I'd do my best to nack the relevant kernel parts), but... Why is execmem part of MAC policy in the first place? As I understand it, the point of MAC is to prevent programs (whether malicious, compromised, or just dumb) from doing things to other parts of the system that they have no business doing. execmem restrictions, on the other hand, serves to prevent a program from doing something *to itself* that may make it easier to compromise that program. Note that, by the time you've pwned a daemon hard enough to get it to call personality, mprotect, or *write another ELF image with strange flags*[1], you've already gotten past the point where preventing execmem is going to do any good. IOW, I consider restrictions to execmem to be in the same category as -fstack-protector, and I'd be happier if this stuff were split out from selinux entirely. (To be fair, if the point is to make it more transparent which programs are using execmem for legitimate purposes, so that the rest can be fixed, then something like file labels makes sense. On the other hand, sticking an equivalent check into, say, the Fedora RPM scripts makes even more sense to me.) [1] Don't even get me started on that one. If you can get a buggy php program to write attacker-controlled files, you're not going to write ELF programs that fiddle with PT_GNU_STACK. You're going to write ELF programs that *already contain shellcode*. So this particular protection is IMO completely worthless. --Andy -- 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
Daniel J Walsh wrote: Here is the request from upstream to enable this feature in Rawhide, with an explanation of what it does. Android is starting to apply execmem and friends to the non-Dalvik components (i.e. non-Java components, primarily the native system daemons). As part of that, I uploaded a change to effectively echo 0 /sys/fs/selinux/checkreqprot so that we always check the actual protection flags applied by the kernel rather than only checking what the application requested. Originally checkreqprot was to support legacy applications that had no PT_GNU_STACK marking or were marked with PT_GNU_STACK RWE, so that we wouldn't have to add execute permission pervasively to policy for such applications. But it effectively provides a way to bypass policy by creating such an application, and as I later discovered, just by calling personality(READ_IMPLIES_EXEC) from an application at any time. The simplest way to eliminate that bypass comprehensively is to change the defaults for checkreqprot. I think this is likely safe in Fedora since you now allow execmem by default to most domains. Can we get the same change applied in Fedora, either by changing the default kernel configuration (CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=0) or by putting something in an init script to set the /sys/fs/selinux/checkreqprot value? I'm afraid all I understand of that explanation is that this has something to do with executable stacks. How does the proposed change affect programs that need an executable stack? Björn Persson signature.asc Description: PGP signature -- 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/24/2014 02:11 PM, Björn Persson wrote: Daniel J Walsh wrote: Here is the request from upstream to enable this feature in Rawhide, with an explanation of what it does. Android is starting to apply execmem and friends to the non-Dalvik components (i.e. non-Java components, primarily the native system daemons). As part of that, I uploaded a change to effectively echo 0 /sys/fs/selinux/checkreqprot so that we always check the actual protection flags applied by the kernel rather than only checking what the application requested. Originally checkreqprot was to support legacy applications that had no PT_GNU_STACK marking or were marked with PT_GNU_STACK RWE, so that we wouldn't have to add execute permission pervasively to policy for such applications. But it effectively provides a way to bypass policy by creating such an application, and as I later discovered, just by calling personality(READ_IMPLIES_EXEC) from an application at any time. The simplest way to eliminate that bypass comprehensively is to change the defaults for checkreqprot. I think this is likely safe in Fedora since you now allow execmem by default to most domains. Can we get the same change applied in Fedora, either by changing the default kernel configuration (CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=0) or by putting something in an init script to set the /sys/fs/selinux/checkreqprot value? I'm afraid all I understand of that explanation is that this has something to do with executable stacks. How does the proposed change affect programs that need an executable stack? Björn Persson No, we pretty much allow executable stack/memory from user processes now and block it for most daemons, except for those that need it. My understanding of this change is that the kernel was not doing complete checking, but most apps at this point do the right thing. We will turn it on in Rawhide and through the beta. If we see problems we will revert. It is now a one line change in # grep check /lib/tmpfiles.d/selinux-policy.conf w /sys/fs/selinux/checkreqprot 1 I believe you can revert it by adding echo w /sys/fs/selinux/checkreqprot 0 /etc/tmpfiles.d/selinux-policy.conf -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLivPsACgkQrlYvE4MpobMODQCgxDzqQZEwAVB3PeLPkDB5t4jI FFcAnRpPxMSQO1ymoxEsDaxU64qCGxMq =oI08 -END PGP SIGNATURE- -- 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: I want to turn on a part of the kernel to make SELinux checking more stringent.
On 24.01.2014 21:20, Daniel J Walsh wrote: No, we pretty much allow executable stack/memory from user processes now and block it for most daemons, except for those that need it. My understanding of this change is that the kernel was not doing complete checking, but most apps at this point do the right thing. We will turn it on in Rawhide and through the beta. If we see problems we will revert. It is now a one line change in SELinux newbie question: Where the daemons exception is actually defined. My practical interest is: What should be added to LuaJIT [1] to be able to run e.g. non-packaged web servers like [2]? Thanks, Alek [1] http://pkgs.fedoraproject.org/cgit/luajit.git/plain/luajit.spec [2] https://github.com/kernelsauce/turbo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
