I want to turn on a part of the kernel to make SELinux checking more stringent.

[Daniel J Walsh]

-----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?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlLihVAACgkQrlYvE4MpobNpZACfbC5WmT7GUirmcBIri1BJOs33
> DcMAnA24d4xumzT4vBPWbLSeEnQwj1VU
> =Kswu
> -----END PGP SIGNATURE-----

[Lennart Poettering]

On Fri, 24.01.14 10:22, Daniel J Walsh (dwalsh(a)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

[Daniel J Walsh]

-----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 (dwalsh(a)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-----

[Daniel J Walsh]

-----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-----

[Andrew Lutomirski]

On Fri, Jan 24, 2014 at 8:01 AM, Daniel J Walsh <dwalsh(a)redhat.com&gt; 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

[Björn Persson]

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

[Daniel J Walsh]

-----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-----

[Alek Paunov]

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

[Daniel J Walsh]

-----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-----

[Richard W.M. Jones]

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/

[Andrew Lutomirski]

On Sun, Jan 26, 2014 at 12:38 PM, Richard W.M. Jones <rjones(a)redhat.com&gt; 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(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Daniel J Walsh]

-----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
> <rjones(a)redhat.com&gt;
>  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(a)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-----

[drago01]

On Sun, Jan 26, 2014 at 9:38 PM, Richard W.M. Jones <rjones(a)redhat.com&gt; 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.

[Matthew Garrett]

On Sun, Jan 26, 2014 at 08:38:25PM +0000, 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 | mjg59(a)srcf.ucam.org

[Till Maas]

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

[Benjamin Lewis]

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

[Zbigniew Jędrzejewski-Szmek]

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

[Jóhann B. Guðmundsson]

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

[Bill Nottingham]

Daniel J Walsh (dwalsh(a)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

[Kevin Kofler]

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