<div id="geary-body" dir="auto">Let me start by apologizing here - I'm feeling a bit silly...<div><br></div><div>how about 'becomeroot' or 'iwannaplaygod' or 'rootme' or maybe even 'meroot'  or 'beroot'</div><div><br></div><div>Yeah, sorry, but remember I did apologize first! ;-)</div><div>And, of course, DON'T POST what you made it!</div></div><div id="geary-quote" dir="auto"><br>On Wed, Jul 3, 2024 at 07:59, Michael via PLUG-discuss <plug-discuss@lists.phxlinux.org> wrote:<br><blockquote type="cite"><div dir="ltr">I've figured out how I'm going to secure my system. I will link sudo to another command and then create an alias for sudo that will echo something like, 'Sudo has been disabled,' if I forget. Now I need suggestions on what to use. Chat gpt suggests supersudo but that's too long. What do you all think?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 2, 2024 at 11:42 PM George Toft via PLUG-discuss <<a href="mailto:plug-discuss@lists.phxlinux.org">plug-discuss@lists.phxlinux.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Okay, I now come begging for more information on why RH thinks sudo is <br>
bad. But first a little background...<br>
<br>
Where I work, the first thing we do is remove sudo and replace it with a <br>
shell script that calls our centralized Privileged Access Management <br>
(PAM) system (not naming vendor). The use of sudo requires and exception <br>
and review and is not permanent. So I'm very versed on the principles <br>
and implementation of PAM. Last year our Staff Architect asked me to <br>
compare and contrast sudo against <unnamed product>. Side-by-side, <br>
feature-by-feature, I did so, based on our POC's on Red Hat Identity <br>
Manager (IdM), which uses sudo, and locally engineered solutions.<br>
<br>
I personally detest sudo because it's like chmod 777 * - makes <br>
everything work so much better, and software vendors can just drop in <br>
their own sudo rules in /etc/sudoers.d/ and make magic happen without <br>
you ever knowing what happened. Several times we've had to convert some <br>
vendor's sudo rules to our own system's rules, and I ask the vendor "Why <br>
do you have this rule?" Their answer: "We don't know." OFFS :(<br>
<br>
As far as sudo goes, it is included in the Center for Internet <br>
Security's (CIS) Benchmarks, which is the embodiment of the information <br>
security industry's best practices. I did some work for them for a <br>
couple years, and every change (add/mod/delete) required consensus <br>
approval from 80 organizations around the world, including thee letter <br>
agencies in the US and abroad. Many/most auditors expect financial <br>
institutions to follow this guide, or explain convincingly why not. So <br>
every six months, we get to say: "We don't use sudo. Instead, we do <br>
this." And then we get to do live demos of timed privileged access. <br>
Haven't had a follow-on question in the last 8 years.<br>
<br>
(OT: I cringe at referring to CIS because of their collusion with the <br>
Arizona Secretary of State and the Department of Homeland Security to <br>
suppress people's First Amendment Right to Free Speech. Proof is in the <br>
Elon Musk Twitter Dump. I do not have a copy of the email on my <br>
computer. I generally don't tell people I did work for them - it's so <br>
embarrassing. Effing Ratbastards.)<br>
<br>
So... back to the original question, as I was not able to find anything <br>
saying Red Hat discourages sudo, nor was my favorite AI. Please toss me <br>
a cookie...<br>
<br>
Regards,<br>
<br>
George Toft<br>
<br>
On 6/26/2024 12:23 PM, Rusty Carruth via PLUG-discuss wrote:<br>
> Actually, I'd like to start a bit of a discussion on this.<br>
><br>
><br>
> First, I know that for some reason RedHat seems to think that sudo is <br>
> bad/insecure.<br>
><br>
> I'd like to know the logic there, as I think the argument FOR using <br>
> sudo is MUCH stronger than any argument I've heard (which, admittedly, <br>
> is pretty close to zero) AGAINST it.   Here's my thinking:<br>
><br>
> Allowing users to become root via sudo gives you:<br>
><br>
>  - VERY fine control over what programs a user can use as root<br>
><br>
>  - The ability to remove admin privs (ability to run as root) from an <br>
> individual WITHOUT having to change root password everywhere.<br>
><br>
> Now, remember, RH is supposedly 'corporate friendly'.  As a <br>
> corporation, that 2nd feature is well worth the price of admission, <br>
> PLUS I can only allow certain admins to run certain programs? Very nice.<br>
><br>
> So, for example, at my last place I allowed the 'tester' user to run <br>
> fdisk as root, because they needed to partition the disk under test.  <br>
> In my case, and since the network that we ran on was totally isolated <br>
> from the corporate network, I let fdisk be run without needing a <br>
> password.  Oh, and if they messed up and fdisk'ed the boot partition, <br>
> it was no big deal - I could recreate the machine from scratch (minus <br>
> whatever data hadn't been copied off yet - which would only be their <br>
> most recent run), in 10 minutes (which was about 2 minutes of my time, <br>
> and 8 minutes of scripted 'dd' ;-)  However, if the test user wanted <br>
> to become root using su, they had to enter the test user password.<br>
><br>
> So, back to the original question - setting sudo to not require a <br>
> password.  We should have asked, what program do you want to run as <br>
> root without requiring a password?  How secure is your system? What <br>
> else do you use it for?  Who has access?  etc, etc, etc.<br>
><br>
> There's one other minor objection I have to the 'zero defense' <br>
> statement below - the malicious thing you downloaded (and, I assume <br>
> ran) has to be written to USE sudo in its attempt to break in, I <br>
> believe, or it wouldn't matter HOW open your sudo was. (simply saying <br>
> 'su - myscript' won't do it).<br>
><br>
> And, if you're truly paranoid about stuff you download, you should:<br>
><br>
> 1 - NEVER download something you don't have an excellent reason to <br>
> believe is 'safe', and ALWAYS make sure you actually downloaded it <br>
> from where you thought you did.<br>
><br>
> 2 - For the TRULY paranoid, have a machine you use to download and <br>
> test software on, which you can totally disconnect from your network <br>
> (not JUST the internet), and which has NO confidential info, and which <br>
> you can erase and rebuild without caring.  Run the downloaded stuff <br>
> there, for a long time, until you're pretty sure it won't bite you.<br>
><br>
> 3 - For the REALLY REALLY paranoid, don't download anything from <br>
> anywhere, disconnect from the internet permanently, get high-tech <br>
> locks for your doors, and wrap your house in a faraday cage!<br>
><br>
> And probably don't leave the house....<br>
><br>
> The point of number 3 is that there is always a risk, even with <br>
> 'well-known' software, and as someone else said - they're watching you <br>
> anyway.  The question is how 'safe' do you want to be? And how <br>
> paranoid are you, really?<br>
><br>
> Wow, talk about rabbit hole! ;-)<br>
><br>
> 'Let the flames begin!' :-)<br>
><br>
><br>
> On 6/25/24 18:50, Ryan Petris via PLUG-discuss wrote:<br>
>>> wanted sudo not to require a password.<br>
>> Please reconsider this... This is VERY BAD security practice. There's <br>
>> basically zero defense if you happen to download/run something <br>
>> malicious.<br>
>><br>
>> On Tue, Jun 25, 2024, at 6:01 PM, Michael via PLUG-discuss wrote:<br>
>>>   then I remember that a PLUG member mentioned ChatGPT being good at <br>
>>> troubleshooting so I figured I'd give it a go. I sprint about half <br>
>>> an hour asking it the wrong question but after that it took 2 <br>
>>> minutes. I wanted sudo not to require a password. it is wonderful! <br>
>>> now I don't have to bug you guys. so it looks like this is the end <br>
>>> of the user group unless you want to talk about OT stuff.<br>
>>><br>
>>> -- <br>
>>> :-)~MIKE~(-:<br>
>>> ---------------------------------------------------<br>
>>> PLUG-discuss mailing list: <a href="mailto:PLUG-discuss@lists.phxlinux.org" target="_blank">PLUG-discuss@lists.phxlinux.org</a><br>
>>> To subscribe, unsubscribe, or to change your mail settings:<br>
>>> <a href="https://lists.phxlinux.org/mailman/listinfo/plug-discuss" rel="noreferrer" target="_blank">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a><br>
>>><br>
>><br>
>> ---------------------------------------------------<br>
>> PLUG-discuss mailing list: <a href="mailto:PLUG-discuss@lists.phxlinux.org" target="_blank">PLUG-discuss@lists.phxlinux.org</a><br>
>> To subscribe, unsubscribe, or to change your mail settings:<br>
>> <a href="https://lists.phxlinux.org/mailman/listinfo/plug-discuss" rel="noreferrer" target="_blank">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a><br>
> ---------------------------------------------------<br>
> PLUG-discuss mailing list: <a href="mailto:PLUG-discuss@lists.phxlinux.org" target="_blank">PLUG-discuss@lists.phxlinux.org</a><br>
> To subscribe, unsubscribe, or to change your mail settings:<br>
> <a href="https://lists.phxlinux.org/mailman/listinfo/plug-discuss" rel="noreferrer" target="_blank">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a><br>
---------------------------------------------------<br>
PLUG-discuss mailing list: <a href="mailto:PLUG-discuss@lists.phxlinux.org" target="_blank">PLUG-discuss@lists.phxlinux.org</a><br>
To subscribe, unsubscribe, or to change your mail settings:<br>
<a href="https://lists.phxlinux.org/mailman/listinfo/plug-discuss" rel="noreferrer" target="_blank">https://lists.phxlinux.org/mailman/listinfo/plug-discuss</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><span style="font-size:12.8px">:-)~MIKE~(-:</span><br></div></div></div></div></div>
</blockquote></div>