Re: sudo remove -s and -i option

Paul Cantle <[email protected]>
Newsgroups gmane.comp.tools.sudo.user
Message-ID <607FC82FA86D7259.4A532AE4-7B8B-4130-9E0E-875FAB417451@mail.outlook.com>
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" <[email protected]<mailto:[email protected]>> 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 <[email protected]><mailto:[email protected]>
Date: Wednesday, 23 August 2017 at 15:54
To: Shawn McMahon <[email protected]><mailto:[email protected]>, Paul Cantle <[email protected]><mailto:[email protected]>
Cc: Maarten de Vries <[email protected]><mailto:[email protected]>, "[email protected]"<mailto:[email protected]> <[email protected]><mailto:[email protected]>
Subject: Re: [sudo-users] sudo remove -s and -i option

here is the result:

user1@kickseed:~$ sudo awk 'BEGIN {system("/bin/sh")}'
sh: 1: Syntax error: "(" unexpected
user1@kickseed:~$ sudo vim <esc> :sh
-su: esc: No such file or directory
wujiyu@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 <[email protected]<mailto:[email protected]>> 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" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> wrote:

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

    user1@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" <[email protected]<mailto:[email protected]>
    > <mailto:[email protected]<mailto:[email protected]>>> 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 <[email protected]<mailto:[email protected]>>
    For list information, options, or to unsubscribe, visit:
    https://www.sudo.ws/mailman/listinfo/sudo-users

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




____________________________________________________________
sudo-users mailing list <[email protected]>
For list information, options, or to unsubscribe, visit:
https://www.sudo.ws/mailman/listinfo/sudo-users
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.