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
On 7/3/2024 4:40 PM, Ryan Petris wrote:
>> I personally detest sudo because it's like chmod 777 * - makes
>> 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:
>
> 1. 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.
> 2. 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:
>> >>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>> >>>
>> >>
>> >> ---------------------------------------------------
>> >> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
>> >> To subscribe, unsubscribe, or to change your mail settings:
>> >> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>> > ---------------------------------------------------
>> > PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
>> > To subscribe, unsubscribe, or to change your mail settings:
>> > https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>> ---------------------------------------------------
>> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>---------------------------------------------------
PLUG-discuss mailing list:
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)