Let me start by apologizing here - I'm feeling a bit silly...

how about 'becomeroot' or 'iwannaplaygod' or 'rootme' or maybe even 'meroot'  or 'beroot'

Yeah, sorry, but remember I did apologize first! ;-)
And, of course, DON'T POST what you made it!

On Wed, Jul 3, 2024 at 07:59, Michael via PLUG-discuss <plug-discuss@lists.phxlinux.org> wrote:
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?

On Tue, Jul 2, 2024 at 11:42 PM George Toft via PLUG-discuss <plug-discuss@lists.phxlinux.org> 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


--
:-)~MIKE~(-: