<!DOCTYPE html><html><head><title></title><style type="text/css">
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><blockquote type="cite"><div>You would be amazed at how many vendors ship products that: <span class="font" style="font-family:monospace;">chmod 777</span> output files, or have the file
perms defined in the RPM as 666 or 777, or create files in <span class="font" style="font-family:monospace;">/tmp</span>. Pretty sad.<br></div></blockquote><div><br></div><div>Yeah... whenever I've seen stuff like that in the past I suggest we not use that vendor because they don't know what they're doing.<br></div><div><br></div><blockquote type="cite"><div>Since we're on the topic of rooting a box, here's a project I've
been working on: <a href="https://gtfobins.github.io/" class="qt-moz-txt-link-freetext">https://gtfobins.github.io/</a> -
it lists 390 ways to read files with privilege or outright spawn a
root shell.<br></div></blockquote><div><br></div><div>This is the same reason why docker has a big fat warning about not allowing regular users access to docker, because it can be used just for this. Just spin up a container with / mapped somewhere in the container and poof you now have root access to the filesystem.<br></div><div><br></div><div>I don't know of any examples off the top of my head, but there's also programs that <i>think</i> they need root but function just fine without it, in which case using fakeroot would be sufficient.<br></div><div><br></div><div>On Wed, Jul 3, 2024, at 10:47 PM, George Toft wrote:<br></div><blockquote type="cite" id="qt" style=""><p>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 <span class="font" style="font-family:monospace;">sudo</span> 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.<br></p><p>You would be amazed at how many vendors ship products that: <span class="font" style="font-family:monospace;">chmod 777</span> output files, or have the file
perms defined in the RPM as 666 or 777, or create files in <span class="font" style="font-family:monospace;">/tmp</span>. Pretty sad.<br></p><p>Since we're on the topic of rooting a box, here's a project I've
been working on: <a href="https://gtfobins.github.io/" class="qt-moz-txt-link-freetext">https://gtfobins.github.io/</a> -
it lists 390 ways to read files with privilege or outright spawn a
root shell.<br></p><p>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 <span class="font" style="font-family:monospace;">sudo
systemctl</span> and get a root shell (see <a href="https://gtfobins.github.io/gtfobins/systemctl/" class="qt-moz-txt-link-freetext">https://gtfobins.github.io/gtfobins/systemctl/</a>).
We have blocked that. The user must specify exactly what
parameters they need for <span class="font" style="font-family:monospace;">systemctl</span>.
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.<br></p><p>Note I used <span class="font" style="font-family:monospace;">sudo</span> 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 <span class="font" style="font-family:monospace;">sudo</span> and the wrapper works flawlessly.<br></p><pre class="qt-moz-signature" cols="72">Regards,
George Toft<br></pre><div class="qt-moz-cite-prefix">On 7/3/2024 4:40 PM, Ryan Petris wrote:<br></div><blockquote type="cite" cite="mid:c7933382-11c0-4e92-9add-dc4a36f6f672@app.fastmail.com"><blockquote type="cite"><div>I personally detest sudo because it's like chmod 777 * -
makes <br></div><div>everything work so much better<br></div></blockquote><div><br></div><div>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 <i>always</i> a better solution.<br></div><div><br></div><blockquote type="cite" id="qt-qt" style=""><div>why RH thinks sudo is bad.<br></div></blockquote><div><br></div><div>The reason why it's bad is a combination of things:<br></div><ol><li>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.<br></li><li>It has so many different rules and whatnot that it could be
easily misconfiguration to allow people sudo access that
shouldn't have it.<br></li></ol><div>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.<br></div><div><br></div><div>IMO, the even better solution is the the new "run0" command,
or "systemd-run", which solves both issues. It's <i>not</i> 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.<br></div><div><br></div><div>On Tue, Jul 2, 2024, at 7:05 PM, George Toft via PLUG-discuss
wrote:<br></div><blockquote type="cite" id="qt-qt" style=""><div>Okay, I now come begging for more information on why RH
thinks sudo is <br></div><div>bad. But first a little background...<br></div><div><br></div><div>Where I work, the first thing we do is remove sudo and
replace it with a <br></div><div>shell script that calls our centralized Privileged Access
Management <br></div><div>(PAM) system (not naming vendor). The use of sudo requires
and exception <br></div><div>and review and is not permanent. So I'm very versed on the
principles <br></div><div>and implementation of PAM. Last year our Staff Architect
asked me to <br></div><div>compare and contrast sudo against <unnamed product>.
Side-by-side, <br></div><div>feature-by-feature, I did so, based on our POC's on Red Hat
Identity <br></div><div>Manager (IdM), which uses sudo, and locally engineered
solutions.<br></div><div><br></div><div>I personally detest sudo because it's like chmod 777 * -
makes <br></div><div>everything work so much better, and software vendors can
just drop in <br></div><div>their own sudo rules in /etc/sudoers.d/ and make magic
happen without <br></div><div>you ever knowing what happened. Several times we've had to
convert some <br></div><div>vendor's sudo rules to our own system's rules, and I ask
the vendor "Why <br></div><div>do you have this rule?" Their answer: "We don't know." OFFS
:(<br></div><div><br></div><div>As far as sudo goes, it is included in the Center for
Internet <br></div><div>Security's (CIS) Benchmarks, which is the embodiment of the
information <br></div><div>security industry's best practices. I did some work for
them for a <br></div><div>couple years, and every change (add/mod/delete) required
consensus <br></div><div>approval from 80 organizations around the world, including
thee letter <br></div><div>agencies in the US and abroad. Many/most auditors expect
financial <br></div><div>institutions to follow this guide, or explain convincingly
why not. So <br></div><div>every six months, we get to say: "We don't use sudo.
Instead, we do <br></div><div>this." And then we get to do live demos of timed privileged
access. <br></div><div>Haven't had a follow-on question in the last 8 years.<br></div><div><br></div><div>(OT: I cringe at referring to CIS because of their
collusion with the <br></div><div>Arizona Secretary of State and the Department of Homeland
Security to <br></div><div>suppress people's First Amendment Right to Free Speech.
Proof is in the <br></div><div>Elon Musk Twitter Dump. I do not have a copy of the email
on my <br></div><div>computer. I generally don't tell people I did work for them
- it's so <br></div><div>embarrassing. Effing Ratbastards.)<br></div><div><br></div><div>So... back to the original question, as I was not able to
find anything <br></div><div>saying Red Hat discourages sudo, nor was my favorite AI.
Please toss me <br></div><div>a cookie...<br></div><div><br></div><div>Regards,<br></div><div><br></div><div>George Toft<br></div><div><br></div><div>On 6/26/2024 12:23 PM, Rusty Carruth via PLUG-discuss
wrote:<br></div><div>> Actually, I'd like to start a bit of a discussion on
this.<br></div><div>><br></div><div>><br></div><div>> First, I know that for some reason RedHat seems to
think that sudo is <br></div><div>> bad/insecure.<br></div><div>><br></div><div>> I'd like to know the logic there, as I think the
argument FOR using <br></div><div>> sudo is MUCH stronger than any argument I've heard
(which, admittedly, <br></div><div>> is pretty close to zero) AGAINST it. Here's my
thinking:<br></div><div>><br></div><div>> Allowing users to become root via sudo gives you:<br></div><div>><br></div><div>> - VERY fine control over what programs a user can use
as root<br></div><div>><br></div><div>> - The ability to remove admin privs (ability to run
as root) from an <br></div><div>> individual WITHOUT having to change root password
everywhere.<br></div><div>><br></div><div>> Now, remember, RH is supposedly 'corporate friendly'.
As a <br></div><div>> corporation, that 2nd feature is well worth the price
of admission, <br></div><div>> PLUS I can only allow certain admins to run certain
programs? Very nice.<br></div><div>><br></div><div>> So, for example, at my last place I allowed the
'tester' user to run <br></div><div>> fdisk as root, because they needed to partition the
disk under test. <br></div><div>> In my case, and since the network that we ran on was
totally isolated <br></div><div>> from the corporate network, I let fdisk be run without
needing a <br></div><div>> password. Oh, and if they messed up and fdisk'ed the
boot partition, <br></div><div>> it was no big deal - I could recreate the machine from
scratch (minus <br></div><div>> whatever data hadn't been copied off yet - which would
only be their <br></div><div>> most recent run), in 10 minutes (which was about 2
minutes of my time, <br></div><div>> and 8 minutes of scripted 'dd' ;-) However, if the
test user wanted <br></div><div>> to become root using su, they had to enter the test
user password.<br></div><div>><br></div><div>> So, back to the original question - setting sudo to
not require a <br></div><div>> password. We should have asked, what program do you
want to run as <br></div><div>> root without requiring a password? How secure is your
system? What <br></div><div>> else do you use it for? Who has access? etc, etc,
etc.<br></div><div>><br></div><div>> There's one other minor objection I have to the 'zero
defense' <br></div><div>> statement below - the malicious thing you downloaded
(and, I assume <br></div><div>> ran) has to be written to USE sudo in its attempt to
break in, I <br></div><div>> believe, or it wouldn't matter HOW open your sudo was.
(simply saying <br></div><div>> 'su - myscript' won't do it).<br></div><div>><br></div><div>> And, if you're truly paranoid about stuff you
download, you should:<br></div><div>><br></div><div>> 1 - NEVER download something you don't have an
excellent reason to <br></div><div>> believe is 'safe', and ALWAYS make sure you actually
downloaded it <br></div><div>> from where you thought you did.<br></div><div>><br></div><div>> 2 - For the TRULY paranoid, have a machine you use to
download and <br></div><div>> test software on, which you can totally disconnect
from your network <br></div><div>> (not JUST the internet), and which has NO confidential
info, and which <br></div><div>> you can erase and rebuild without caring. Run the
downloaded stuff <br></div><div>> there, for a long time, until you're pretty sure it
won't bite you.<br></div><div>><br></div><div>> 3 - For the REALLY REALLY paranoid, don't download
anything from <br></div><div>> anywhere, disconnect from the internet permanently,
get high-tech <br></div><div>> locks for your doors, and wrap your house in a faraday
cage!<br></div><div>><br></div><div>> And probably don't leave the house....<br></div><div>><br></div><div>> The point of number 3 is that there is always a risk,
even with <br></div><div>> 'well-known' software, and as someone else said -
they're watching you <br></div><div>> anyway. The question is how 'safe' do you want to be?
And how <br></div><div>> paranoid are you, really?<br></div><div>><br></div><div>> Wow, talk about rabbit hole! ;-)<br></div><div>><br></div><div>> 'Let the flames begin!' :-)<br></div><div>><br></div><div>><br></div><div>> On 6/25/24 18:50, Ryan Petris via PLUG-discuss wrote:<br></div><div>>>> wanted sudo not to require a password.<br></div><div>>> Please reconsider this... This is VERY BAD
security practice. There's <br></div><div>>> basically zero defense if you happen to
download/run something <br></div><div>>> malicious.<br></div><div>>><br></div><div>>> On Tue, Jun 25, 2024, at 6:01 PM, Michael via
PLUG-discuss wrote:<br></div><div>>>> then I remember that a PLUG member mentioned
ChatGPT being good at <br></div><div>>>> troubleshooting so I figured I'd give it a go.
I sprint about half <br></div><div>>>> an hour asking it the wrong question but after
that it took 2 <br></div><div>>>> minutes. I wanted sudo not to require a
password. it is wonderful! <br></div><div>>>> now I don't have to bug you guys. so it looks
like this is the end <br></div><div>>>> of the user group unless you want to talk
about OT stuff.<br></div><div>>>><br></div><div>>>> -- <br></div><div>>>> :-)~MIKE~(-:<br></div><div>>>>
---------------------------------------------------<br></div><div>>>> PLUG-discuss mailing list: <a href="mailto:PLUG-discuss@lists.phxlinux.org" class="qt-moz-txt-link-freetext">PLUG-discuss@lists.phxlinux.org</a><br></div><div>>>> To subscribe, unsubscribe, or to change your
mail settings:<br></div><div>>>> <a href="https://lists.phxlinux.org/mailman/listinfo/plug-discuss" class="qt-moz-txt-link-freetext">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a><br></div><div>>>><br></div><div>>><br></div><div>>>
---------------------------------------------------<br></div><div>>> PLUG-discuss mailing list: <a href="mailto:PLUG-discuss@lists.phxlinux.org" class="qt-moz-txt-link-freetext">PLUG-discuss@lists.phxlinux.org</a><br></div><div>>> To subscribe, unsubscribe, or to change your mail
settings:<br></div><div>>> <a href="https://lists.phxlinux.org/mailman/listinfo/plug-discuss" class="qt-moz-txt-link-freetext">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a><br></div><div>> ---------------------------------------------------<br></div><div>> PLUG-discuss mailing list: <a href="mailto:PLUG-discuss@lists.phxlinux.org" class="qt-moz-txt-link-freetext">PLUG-discuss@lists.phxlinux.org</a><br></div><div>> To subscribe, unsubscribe, or to change your mail
settings:<br></div><div>> <a href="https://lists.phxlinux.org/mailman/listinfo/plug-discuss" class="qt-moz-txt-link-freetext">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a><br></div><div>---------------------------------------------------<br></div><div>PLUG-discuss mailing list: <a href="mailto:PLUG-discuss@lists.phxlinux.org" class="qt-moz-txt-link-freetext">PLUG-discuss@lists.phxlinux.org</a><br></div><div>To subscribe, unsubscribe, or to change your mail settings:<br></div><div><a href="https://lists.phxlinux.org/mailman/listinfo/plug-discuss" class="qt-moz-txt-link-freetext">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a><br></div><div><br></div></blockquote><div><br></div></blockquote></blockquote><div><br></div></body></html>