-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?)
-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
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
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
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
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
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
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
-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
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
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
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
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
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
-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
-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
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
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
-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
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
20 matches
Mail list logo
