[sudo-users] sudo remove -s and -i option

[Paul Cantle]

Hi,

I'm pretty sure that everybody that has replied is of the same opinion here. You can't really restrict root shell login effectively. You should just allow the commands you require to be run and not mention any others

Rgds

Paul




On Fri, Aug 25, 2017 at 3:06 AM +0100, "Goodman Leung" <gbcbooksmj at gmail.com<mailto:gbcbooksmj at gmail.com>> wrote:

well,  this is really bad , what is the theory

在 2017/8/23 22:56, Paul Cantle 写道:
No, type this

sudo vim   or sudo vi

Then hit the escape key

Then type

:sh

From: Goodman Leung <gbcbooksmj at gmail.com><mailto:gbcbooksmj at gmail.com>
Date: Wednesday, 23 August 2017 at 15:54
To: Shawn McMahon <syberghost at gmail.com><mailto:syberghost at gmail.com>, Paul Cantle <paul at cantle.me><mailto:paul at cantle.me>
Cc: Maarten de Vries <maarten.de.zoveelste at gmail.com><mailto:maarten.de.zoveelste at gmail.com>, "sudo-users at sudo.ws"<mailto:sudo-users at sudo.ws> <sudo-users at sudo.ws><mailto:sudo-users at sudo.ws>
Subject: Re: [sudo-users] sudo remove -s and -i option

here is the result:

user1 at kickseed:~$ sudo awk 'BEGIN {system("/bin/sh")}'
sh: 1: Syntax error: "(" unexpected
user1 at kickseed:~$ sudo vim <esc> :sh
-su: esc: No such file or directory
wujiyu at kickseed:~$

for:
sudo cp -p /bin/bash foo
sudo ./foo
this is not going to work .
在 2017/8/23 22:52, Shawn McMahon 写道:
It's worse than that. They can do this:

sudo cp -p /bin/bash foo
sudo ./foo -i

You cannot stop shells with blacklisting; not even with NOEXEC. Only whitelisting has a prayer of stopping shells. Where blacklisting is used, it's generally considered to be a reminder that folks shouldn't do that, not a barrier.

You're just creating speed bumps that will engender a lack of respect for Security and Compliance in your users because you don't want to tackle a difficult political problem. You can't solve political problems with technical solutions; especially bad technical solutions.

BTW, NOEXEC is great for restricting the capabilities of whitelisted programs. Using it with "ALL" and a blacklist will result in it breaking things, because that's NOEXEC's job; to break things. But it'll include things you don't want broken.

But do what you want, man; I'm not your mom. Just hope I'm never your auditor.


On Wed, Aug 23, 2017 at 9:37 AM, Paul Cantle <paul at cantle.me<mailto:paul at cantle.me>> wrote:
Hi,

Plenty unless you specify NOEXEC in sudoers – vi, vim, less, awk and probably others.

Examples:

sudo awk 'BEGIN {system("/bin/sh")}' – will give a root shell
sudo vim <esc> :sh – will give a root shell

if people need to be able to edit files as root sudoedit or sudo –e is a safer option.

I cannot stress enough that this isn’t the way to go – Really, you should just limit the commands that people need to execute as root and not mess with the sudo program itself.

Just my 2c

Rgds
Paul



On 23/08/2017, 15:32, "sudo-users on behalf of Goodman Leung" <sudo-users-bounces at sudo.ws<mailto:sudo-users-bounces at sudo.ws> on behalf of gbcbooksmj at gmail.com<mailto:gbcbooksmj at gmail.com>> wrote:

    here is the output when my user execute sudo /bin/bash

    user1 at kickseed:~$ sudo /bin/bash
    Traceback (most recent call last):
       File "<string>", line 92, in <module>
       File "<string>", line 33, in check_element
    IndexError: list index out of range

    i thing they get the same result when they use /bin/sh instead .

    do you know any aother command can get a root shell ?

    在 2017/8/23 16:38, Maarten de Vries 写道:
    >
    >
    > On 23 Aug 2017 4:15 a.m., "Goodman Leung" <gbcbooksmj at gmail.com<mailto:gbcbooksmj at gmail.com>
    > <mailto:gbcbooksmj at gmail.com<mailto:gbcbooksmj at gmail.com>>> wrote:
    >
    >     well ,  before i m doing this, i have another solutions , i write
    >     a security binary to replace /usr/bin/sudo ,
    >
    >     you are not able to execute sudo -s , sudo -i , sudo su , and even
    >     sudo /bin/bash.
    >
    >
    >     would you guys wanna try ?
    >
    >     i just think it is not perfect enough.
    >
    >
    > I think it is a really bad idea. If jou want to prevent users
    > executing arbitrary commands jou MUST whitelist exactly the commands
    > that they should be able to use.
    >
    > Blocking only shells is almost completely pointless because users can
    > still execute *every* other command from their own shell prefixed with
    > sudo. The only thing you would win is that every sudo invocation is
    > logged. But if they want they can destroy all logs on the local system.
    >
    > Also, shells and editors are far from the only tools that allow you to
    > bypass sudo logging. Every script interpreter (python/ruby/perl/etc)
    > can do the same. And then there are many more interactive tools that
    > allow users to run arbitrary commands.
    >
    > And if you did blacklist *everything* (which is impossible), then
    > users can just copy a blacklisted binary to their home folder with a
    > different name so it is not blacklisted anymore.
    >
    > In short: if you want to allow users to run arbitrary commands as
    > root, but not shells, you're pretty much out of luck. If you want to
    > allow them to do some specific things as root, whitelist exactly
    > those. Either way, writing your own sudo is not the solution.
    >
    > -- Maarten

    ____________________________________________________________
    sudo-users mailing list <sudo-users at sudo.ws<mailto:sudo-users at sudo.ws>>
    For list information, options, or to unsubscribe, visit:
    https://www.sudo.ws/mailman/listinfo/sudo-users

____________________________________________________________
sudo-users mailing list <sudo-users at sudo.ws<mailto:sudo-users at sudo.ws>>
For list information, options, or to unsubscribe, visit:
https://www.sudo.ws/mailman/listinfo/sudo-users