[sudo-users] sudo remove -s and -i option
David Ledger
david.ledger at ivdcs.co.uk
Fri Aug 25 03:45:15 MDT 2017
On 25 Aug 2017, at 10:31, Goodman Leung wrote:
> thks for the suggtions
>
> as i said , it need a every long time to change a business system which is already running online for years
>
> through there is ways to promote to root , but we will still as the best as we can to prevent the things happen .
The best way is to have careful, knowledgable people who are as trustworthy as those who wrote and require you to follow the 'Security Policy' think they themselves are.
David
> 在 2017/8/25 14:41, 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>
>>> *Date: *Wednesday, 23 August 2017 at 15:54
>>> *To: *Shawn McMahon <syberghost at gmail.com>, Paul Cantle
>>> <paul at cantle.me>
>>> *Cc: *Maarten de Vries <maarten.de.zoveelste at gmail.com>,
>>> "sudo-users at sudo.ws" <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
>>>
>>>
>>>
>>
>
> ____________________________________________________________
> sudo-users mailing list <sudo-users at sudo.ws>
> For list information, options, or to unsubscribe, visit:
> https://www.sudo.ws/mailman/listinfo/sudo-users
More information about the sudo-users
mailing list