CentOS - Aug 2018 - selinux question

On 08/21/2018 02:20 PM, Warren Young wrote:
> On Aug 21, 2018, at 1:27 PM, Nataraj <incoming-centos at rjl.com>
wrote:
>> I have a web application which uses sudo to invoke python scripts as
the
>> user under which the application runs (NO root access).
> Why is the web app not running with that user?s permissions in the first
place?
>
> If your answer is that it needs root access to bind to port 80, there are
two common solutions:
>
> 1. Start the service as root, set up the port 80 listener, then drop
privileges internally with getpwent(?myuser?) and setuid(my_uid).
>
> 2. Use an HTTP[S] proxy server, such as Apache with mod_proxy configured. 
Bind the actual web app to localhost and a high-numbered random port, then
forward external port 80 hits to the internal service.  This method has the
additional advantage that you can use the path part of the URL to relieves the
web app of having to serve hits for the static resources ? *.js, *.png, *.css? ?
which can speed the application up.
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> https://lists.centos.org/mailman/listinfo/centos
The php code runs as user apache under the webserver.  If the php ran as the app
users it would have full access to all of the data in the app.  Using sudo the
app can only invoke one specific python script (which is the command name in the
sudoers file) to do what it needs to do, without having access to the rest of
the apps data and other python scripts used by other functions in the app).
Could be that I'm not seeing something, but this approach seems sensible to
me, though I could be convinced otherwise if I could see where running the php
as the app users, would make more sense.

It could be that giving sudo sys_ptrace access could increase the risk to the
security of the system, but giving the php code app user access, increases the
risk of data compromise in the app.



Thank You,
Nataraj

On Aug 21, 2018, at 4:34 PM, Nataraj <incoming-centos at rjl.com>
wrote:
> 
> On 08/21/2018 02:20 PM, Warren Young wrote:
>> On Aug 21, 2018, at 1:27 PM, Nataraj <incoming-centos at rjl.com>
wrote:
>>> I have a web application which uses sudo to invoke python scripts
as the
>>> user under which the application runs (NO root access).
>> Why is the web app not running with that user?s permissions in the
first place?
>> 
> The php code runs as user apache under the webserver.
Okay, that?s useful to know, and it?s something we?re just now learning.  You?ll
get better advice if you include such details when using for help.
> If the php ran as the app users it would have full access to all of the
data in the app.
?and that?s a problem why, exactly?  What could happen if that were allowed?

I understand that you?re creating a privilege separation scheme here, but if you
want good advice, we need to know what you want to achieve with the scheme and
why that is necessary.

What resources does this non-php user own that user php must not be allowed to
have access to?  Once we know that, we can advise on how to protect those
resources.
> Using sudo the app can only invoke one specific python script (which is the
command name in the sudoers file) to do what it needs to do, without having
access to the rest of the apps data and other python scripts used by other
functions in the app).
Another way to go about it would be to have the background service running as
the non-php user, then provide access to it over the many IPC mechanisms
available in a Linux system: named pipes, SysV message queues, shared memory? 
Add to that all of the higher-level services available like message-oriented
middleware:

   https://en.wikipedia.org/wiki/Category:Message-oriented_middleware

Such services let one process tell another, ?Hey, I need you to do something for
me,? then wait for the answer, received as a single coherent message.  Many of
these schemes let you split that worker process off into a separate machine, or
even a cluster of machines.

That could help you to get off CentOS 5: move the worker process onto a C7 box,
then when that?s well-validated, move the PHP bits over.

Or, move the PHP bits to a *second* C7 box, and now you?ve got much stronger
privilege separation.  You may remember all of the ways that Shellshock ? a
local-only exploit ? was able to be exploited over HTTP, because local web app
code was using the shell, thus converting it into a remote-exploitable security
hole.  By separating the worker processes to a separate machine, that now can?t
happen on the second box.  If the front-end box has no sensitive material on it,
that?s enough security: just wipe it and re-image it if it?s ever compromised.

However you do this, these mechanisms give you hard privilege separation without
SELinux bugging you.
> I could be convinced otherwise if I could see where running the php as the
app users, would make more sense.
That depends on whether the boundary between user php and this unknown ?appuser?
is bidirectional or not.

If there are things owned by user ?php? that ?appuser? should not see, then
continuing to run the web app as two separate users makes sense.

If ?appuser? can be said to own everything in the web app, and the only reason
you?re converting user php privileges to ?appuser? privileges is so you don?t
have to give user php access to everything in the web app, then I?d say my prior
suggestion holds.

Now that I know you?re using PHP, I can recommend something like PHP-FPM:

    https://php-fpm.org/

That?s the old external project.  It?s now part of the PHP core:

    https://secure.php.net/manual/en/install.fpm.php

You?ll have to use the old version with C5, though, as that happened after C5
was released.

FPM isn?t the only way to go, just one idea, which happens to be well-supported
within the PHP community.

Regardless of the exact method, this lets you run your PHP code as a non-php
user, letting Apache proxy to it using mod_fcgi.  Now you?ve got strong
separation between things Apache is allowed to read and things it must talk down
through PHP to get access to.
> It could be that giving sudo sys_ptrace access could increase the risk to
the security of the system
Once you give a process ptrace ability, it?s pretty much game over when it comes
to security.  The scope of what one process can do to another via ptrace(2) is
HUUUUGE.  I?d very much resist placating SELinux in this way.

SELinux might in fact be warning you about a real attack here, which would
explain why it?s intermittent.

On 08/21/2018 05:45 PM, Warren Young wrote:
>
>> I could be convinced otherwise if I could see where running the php as
the app users, would make more sense.
> That depends on whether the boundary between user php and this unknown
?appuser? is bidirectional or not.
>
> If there are things owned by user ?php? that ?appuser? should not see, then
continuing to run the web app as two separate users makes sense.
>
> If ?appuser? can be said to own everything in the web app, and the only
reason you?re converting user php privileges to ?appuser? privileges is so you
don?t have to give user php access to everything in the web app, then I?d say my
prior suggestion holds.
>
> Now that I know you?re using PHP, I can recommend something like PHP-FPM:
>
>     https://php-fpm.org/
>
> That?s the old external project.  It?s now part of the PHP core:
>
>     https://secure.php.net/manual/en/install.fpm.php
>
> You?ll have to use the old version with C5, though, as that happened after
C5 was released.
>
> FPM isn?t the only way to go, just one idea, which happens to be
well-supported within the PHP community.
>
> Regardless of the exact method, this lets you run your PHP code as a
non-php user, letting Apache proxy to it using mod_fcgi.  Now you?ve got strong
separation between things Apache is allowed to read and things it must talk down
through PHP to get access to.
>
>> It could be that giving sudo sys_ptrace access could increase the risk
to the security of the system
> Once you give a process ptrace ability, it?s pretty much game over when it
comes to security.  The scope of what one process can do to another via
ptrace(2) is HUUUUGE.  I?d very much resist placating SELinux in this way.
>
> SELinux might in fact be warning you about a real attack here, which would
explain why it?s intermittent.
> _______________________________________________
Thank you, this information was helpful.? I will solve the problem
without allowing ptrace capability.

Nataraj