Thanks for the explanation - no argument here. I was hoping for a
link from RH that I could pass on to my Staff Architect. Right now
I'm battling the next three layers of manglement above me "to
please OMG don't try to convert back to sudo." I have layer #1
mostly convinced. Silly managers think we can take 15 years of
local engineering, rip it out, and plug in an OTS replacement.
Sure, if you're willing to spend 2 man-years of effort and fail
current audit requirements because sudo
can't block what the Red Team told us to prevent. I figured out
why managers disappear for a couple weeks after promotion - it's
to recover from their lobotomy.
You would be amazed at how many vendors ship products that: chmod 777 output files, or have the file
perms defined in the RPM as 666 or 777, or create files in /tmp. Pretty sad.
Since we're on the topic of rooting a box, here's a project I've been working on: https://gtfobins.github.io/ - it lists 390 ways to read files with privilege or outright spawn a root shell.
Now I have customized the company's PAM solution to block almost
all of them (rest to be completed soon). Before local
re-engineering, you could say sudo
systemctl and get a root shell (see https://gtfobins.github.io/gtfobins/systemctl/).
We have blocked that. The user must specify exactly what
parameters they need for systemctl.
And that's where I get to be the BOFH - LOL. Poke around the GTFO
website - some of the attacks are pretty obvious - some are pretty
ingenious.
Note I used sudo above - we have a
wrapper that converts sudo syntax to <vendor product binary
that shall not be named> and then invokes the <vendor
binary>. In 99.9% of the cases over the last several years,
<vendor product> works just like sudo
and the wrapper works flawlessly.
Regards, George Toft
everything work so much better
Please, please, PLEASE! I beg of you! Please do not chmod 777 stuff! This is even worse! You're just allowing all users to modify said files tearing down any kind of privilege separation there might be. There is always a better solution.
why RH thinks sudo is bad.
The reason why it's bad is a combination of things:
- It's an executable with the suid bit set, and thus the binary itself runs as root whenever you run it. Therefore, any kind of vulnerability in the application is a possible privilege escalation.
- It has so many different rules and whatnot that it could be easily misconfiguration to allow people sudo access that shouldn't have it.
This is why "doas" came to be; it's still an suid executable but has a much smaller ruleset and therefore is much smaller which is a smaller footprint for exploitation.
IMO, the even better solution is the the new "run0" command, or "systemd-run", which solves both issues. It's not an suid executable and therefore bugs in the application won't result in a privilege escalation, and polkit is used to determine who is authorized which is very robust and allows for better configuration than sudo. Systemd itself then starts a new root process in a separate cgroup just as any other service or user environment.
On Tue, Jul 2, 2024, at 7:05 PM, George Toft via PLUG-discuss wrote:
Okay, I now come begging for more information on why RH thinks sudo is
bad. But first a little background...
Where I work, the first thing we do is remove sudo and replace it with a
shell script that calls our centralized Privileged Access Management
(PAM) system (not naming vendor). The use of sudo requires and exception
and review and is not permanent. So I'm very versed on the principles
and implementation of PAM. Last year our Staff Architect asked me to
compare and contrast sudo against <unnamed product>. Side-by-side,
feature-by-feature, I did so, based on our POC's on Red Hat Identity
Manager (IdM), which uses sudo, and locally engineered solutions.
I personally detest sudo because it's like chmod 777 * - makes
everything work so much better, and software vendors can just drop in
their own sudo rules in /etc/sudoers.d/ and make magic happen without
you ever knowing what happened. Several times we've had to convert some
vendor's sudo rules to our own system's rules, and I ask the vendor "Why
do you have this rule?" Their answer: "We don't know." OFFS :(
As far as sudo goes, it is included in the Center for Internet
Security's (CIS) Benchmarks, which is the embodiment of the information
security industry's best practices. I did some work for them for a
couple years, and every change (add/mod/delete) required consensus
approval from 80 organizations around the world, including thee letter
agencies in the US and abroad. Many/most auditors expect financial
institutions to follow this guide, or explain convincingly why not. So
every six months, we get to say: "We don't use sudo. Instead, we do
this." And then we get to do live demos of timed privileged access.
Haven't had a follow-on question in the last 8 years.
(OT: I cringe at referring to CIS because of their collusion with the
Arizona Secretary of State and the Department of Homeland Security to
suppress people's First Amendment Right to Free Speech. Proof is in the
Elon Musk Twitter Dump. I do not have a copy of the email on my
computer. I generally don't tell people I did work for them - it's so
embarrassing. Effing Ratbastards.)
So... back to the original question, as I was not able to find anything
saying Red Hat discourages sudo, nor was my favorite AI. Please toss me
a cookie...
Regards,
George Toft
On 6/26/2024 12:23 PM, Rusty Carruth via PLUG-discuss wrote:
> Actually, I'd like to start a bit of a discussion on this.
>
>
> First, I know that for some reason RedHat seems to think that sudo is
> bad/insecure.
>
> I'd like to know the logic there, as I think the argument FOR using
> sudo is MUCH stronger than any argument I've heard (which, admittedly,
> is pretty close to zero) AGAINST it. Here's my thinking:
>
> Allowing users to become root via sudo gives you:
>
> - VERY fine control over what programs a user can use as root
>
> - The ability to remove admin privs (ability to run as root) from an
> individual WITHOUT having to change root password everywhere.
>
> Now, remember, RH is supposedly 'corporate friendly'. As a
> corporation, that 2nd feature is well worth the price of admission,
> PLUS I can only allow certain admins to run certain programs? Very nice.
>
> So, for example, at my last place I allowed the 'tester' user to run
> fdisk as root, because they needed to partition the disk under test.
> In my case, and since the network that we ran on was totally isolated
> from the corporate network, I let fdisk be run without needing a
> password. Oh, and if they messed up and fdisk'ed the boot partition,
> it was no big deal - I could recreate the machine from scratch (minus
> whatever data hadn't been copied off yet - which would only be their
> most recent run), in 10 minutes (which was about 2 minutes of my time,
> and 8 minutes of scripted 'dd' ;-) However, if the test user wanted
> to become root using su, they had to enter the test user password.
>
> So, back to the original question - setting sudo to not require a
> password. We should have asked, what program do you want to run as
> root without requiring a password? How secure is your system? What
> else do you use it for? Who has access? etc, etc, etc.
>
> There's one other minor objection I have to the 'zero defense'
> statement below - the malicious thing you downloaded (and, I assume
> ran) has to be written to USE sudo in its attempt to break in, I
> believe, or it wouldn't matter HOW open your sudo was. (simply saying
> 'su - myscript' won't do it).
>
> And, if you're truly paranoid about stuff you download, you should:
>
> 1 - NEVER download something you don't have an excellent reason to
> believe is 'safe', and ALWAYS make sure you actually downloaded it
> from where you thought you did.
>
> 2 - For the TRULY paranoid, have a machine you use to download and
> test software on, which you can totally disconnect from your network
> (not JUST the internet), and which has NO confidential info, and which
> you can erase and rebuild without caring. Run the downloaded stuff
> there, for a long time, until you're pretty sure it won't bite you.
>
> 3 - For the REALLY REALLY paranoid, don't download anything from
> anywhere, disconnect from the internet permanently, get high-tech
> locks for your doors, and wrap your house in a faraday cage!
>
> And probably don't leave the house....
>
> The point of number 3 is that there is always a risk, even with
> 'well-known' software, and as someone else said - they're watching you
> anyway. The question is how 'safe' do you want to be? And how
> paranoid are you, really?
>
> Wow, talk about rabbit hole! ;-)
>
> 'Let the flames begin!' :-)
>
>
> On 6/25/24 18:50, Ryan Petris via PLUG-discuss wrote:
>>> wanted sudo not to require a password.
>> Please reconsider this... This is VERY BAD security practice. There's
>> basically zero defense if you happen to download/run something
>> malicious.
>>
>> On Tue, Jun 25, 2024, at 6:01 PM, Michael via PLUG-discuss wrote:
>>> then I remember that a PLUG member mentioned ChatGPT being good at
>>> troubleshooting so I figured I'd give it a go. I sprint about half
>>> an hour asking it the wrong question but after that it took 2
>>> minutes. I wanted sudo not to require a password. it is wonderful!
>>> now I don't have to bug you guys. so it looks like this is the end
>>> of the user group unless you want to talk about OT stuff.
>>>
>>> --
>>> :-)~MIKE~(-:
>>> ---------------------------------------------------
>>> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
>>> To subscribe, unsubscribe, or to change your mail settings:
>>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
> ---------------------------------------------------
> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
---------------------------------------------------
PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings: