Re: [PLUG] LINUX LOW LEVEL PROGRAMMING QUESTION

[Rich Freeman <r-plug@thefreemanclan.net>]

On Mon, Nov 7, 2016 at 9:01 PM, Philip Rushik <prushik@gmail.com> wrote:
> On Mon, Nov 7, 2016 at 8:43 PM, Rich Freeman <r-plug@thefreemanclan.net>
> wrote:
>>
>> sudo != suid.  suid scripts being disabled is unsurprising, because
>> there is a race condition in having them around.
>
>
> I've never heard of a race condition associated with suid, I would like to
> know more about that.

There isn't an issue with suid.  There is an issue with suid scripts.

The gist of it is that the kernel runs bash and then bash opens the
script.  During that interval the script can be replaced and bash is
already running as root and will execute whatever it ends up reading.
I'm sure Google will yield a more complete answer.

I believe the kernel disables suid on anything that uses #! as its
magic number for this reason.  The vulnerability would apply to
anything run this way (bash, dash, python, perl, whatever).

> However, you for sure need to have something that is
> suid, otherwise there is no way to become root (su and sudo use suid, as
> does probably login and some other coreutils on a gnu based system, busybox
> is likely suid on other systems).

Sure, and for binaries there is no race condition, because they're
loaded by the kernel itself. If you modify them before they're loaded
they lose the suid bit, and if you modify them after they're loaded
then COW applies to the image in RAM and the old binary is what is
run.

>> Now, what you can do is put a script in the sudoers file with NOPASSWD
>> and so on, and that is both secure and will let any (designated) users
>> run that script with sudo, and let you call it from other scripts,
>> crontab, and so on I think.
>>
>> The other thing you can do is write a wrapper in C which does nothing
>> but exec the shell script, and make that C wrapper suid.  That is also
>> secure.
>
> This is a good suggestion, but in and of itself it is not secure, it needs
> to be implemented carefully otherwise it would be the first place I would
> start if I wanted to hack your system.

Certainly all the issues you list are valid ones.  This is why you
should never rely on PATH in scripts that run as root and so on.  And
you do have a point that if the script is modified you don't get that
suid bit removal protection that you normally get.

Oh, as far as the issue with > not working in a script goes, I wonder
if that is a noclobber thing.  Try >>, or manipulate the noclobber
settings.  I'm sure JP could explain it better.

-- 
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug