subject:"Re\: trouble adding my user to sudoers list"




Many years ago our founders and many others put it all on the line so we 
could enjoy freedom.


I am so thankful to those brave men and the women who supported them.




On 2024-07-04 15:15, Keith Smith via PLUG-discuss wrote:

I find it interesting that online banking is safer than checks.



On 2024-07-04 14:23, George Toft via PLUG-discuss wrote:

IMHO, Y'all are brave.

Regards,

George Toft

On 7/3/2024 11:31 PM, Steve Litt via PLUG-discuss wrote:

Keith Smith via PLUG-discuss said on Wed, 03 Jul 2024 06:21:25 -0700




On 2024-07-02 18:20, George Toft via PLUG-discuss wrote:

I work for a bank, and you would be amazed at how much security is
baked into the connecting your browser to their web servers. Makes
the NSA look like freshmen. And no, I'm not telling you who I work
for.

Regards,

George Toft
I'd like to hear more.  The world is a hostile place.  I recently 
went
old school.  I asked the bank to disarm my online banking.  I now 
deal

with paper statements and everything gets paid by check.  Not as
convenient as on-line banking, however I am hoping it makes my world 
a

little bit more secure.

I did the exact same thing decades ago.

SteveT

Steve Litt

http://444domains.com
---
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

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)


I find it interesting that online banking is safer than checks.



On 2024-07-04 14:23, George Toft via PLUG-discuss wrote:

IMHO, Y'all are brave.

Regards,

George Toft

On 7/3/2024 11:31 PM, Steve Litt via PLUG-discuss wrote:

Keith Smith via PLUG-discuss said on Wed, 03 Jul 2024 06:21:25 -0700




On 2024-07-02 18:20, George Toft via PLUG-discuss wrote:

I work for a bank, and you would be amazed at how much security is
baked into the connecting your browser to their web servers. Makes
the NSA look like freshmen. And no, I'm not telling you who I work
for.

Regards,

George Toft
I'd like to hear more.  The world is a hostile place.  I recently 
went
old school.  I asked the bank to disarm my online banking.  I now 
deal

with paper statements and everything gets paid by check.  Not as
convenient as on-line banking, however I am hoping it makes my world 
a

little bit more secure.

I did the exact same thing decades ago.

SteveT

Steve Litt

http://444domains.com
---
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

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)


Thanks George!!  Lot s to think about.


On 2024-07-04 14:23, George Toft wrote:



Regards,

George Toft

On 7/4/2024 6:50 AM, techli...@phpcoderusa.com wrote:

Thank you so much George!!

Another Question.  I was a police officer in the 80's and 90's. During 
my tenure the bank was on the hook for any criminal acts as long as 
the customer was not negligent. I only dealt with this on a couple 
occasional.


So If someone gets access to my online banking and I report it in a 
timely manner, or if someone washes one of my checks and I report it 
in a timely manner, is the bank on the hook or am I?


There are a ton of rules with more acronyms than the IT world has. I 
would love to tell you what I understand, but I'd be talking out my 
ass.



BTW I thought going old school was the most secure.  I do not trust 
the Internet.  My daily driver is a Linux Box and I do not use my 
cellular phone for anything except to talk and read some news.  I am 
semiretired and have home officed for a long time.


Not sure there is any magic incantation that I can say that would put 
you at ease, other than "Risk Analysis," "Government Regulation," 
"Audit and Reviews," "Compliance," "Controls and Countermeasures," and 
"Fines." We have to comply with a bazillion rules all designed to 
protect you, the bank customer. Some regions are really strict and 
their governments show they really care, like the EU - their rules are 
so restrictive. Here's an example: You cannot log into a server that 
serves the EU if Payment Card Information (PCI) is involved with the 
same user ID that you used to log into your work station. This prevents 
lateral movement from an insider attack should the attacker get an 
employee's credentials or Kerberos TGT (Hey!!! It's now on-topic!!!) . 
This is just an example. We have external inspectors and government 
auditors on site almost every two weeks making us prove compliance with 
all the rules, and the bigger we get, the more rules and more 
regulatory auditors we get to talk to. We actually have two people on 
my team of 27 whose job used to be project management, now is audit and 
compliance. All of this to protect you.


Let's not forget about the Security Operations Center monitoring 
employee activities. Refer to the GTFOBins email from yesterday. I 
documented a chained attack to get root based on that page, and the SOC 
came knocking saying "George, we noticed suspicious activity on this 
server and this date. Whatcha doin'?" Fortunately, I documented 
everything and emailed it to my manager, so all I had to do was forward 
that back to the SOC.


Mail scares me. I had to send my LEA ID in recently via USPS. I'm 
hoping they got it.




Any suggestions are appreciated.



On 2024-07-03 21:48, George Toft wrote:
Sorry, Kieth, I have bad news for you. You took a 30+ year leap 
backwards in security.


I can tell you for certain, from my bank fraud analyst friend (just 
got promoted to financial crimes investigator), checks are the second 
most insecure way of transferring money, first being putting the 
money in the envelope. They helped the USPS bust a fraud ring who 
worked in the Post Office - fraudsters were pulling checks out of 
envelopes inside the local Post Office. My friend pulled out all the 
details for the Postmaster General.


ACH is free (for you) and secure and guaranteed by the originator as 
they are on the hook to prove the identity of who initiated the 
transaction and they have to pay. It's all very complicated, and I'm 
not going into details here.


I use ACH all the time. My physical devices have multi-layer physical 
protection. Logical access control is in-place. Both have 
multi-factor authentication. Password resets require multi-factor 
authentication.


And the DoD is worse - their systems have so many layers, it was 
easier to just let my account get deleted from lack of use and 
rebuilt it from scratch. I have notes that tell me screen-by-screen 
what to put in each box and which ones to ignore. It's so secure, 
legitimate users can't even get in... and this is just my health 
insurance.


Where all of this can break down - getting on topic - is with the SSH 
protocol and web proxies. When you connect to a website using HTTPS 
using a web proxy, your web browser uses it's cert to set up the 
connection, or so it thinks. What's really happening is the proxy is 
responding to the request and decrypting the message, then it forms a 
new request and sends it to the bank, which believes the proxy and 
sends it back. Everything gets decrypted on the proxy, so whoever has 
admin access to the proxy can see everything. Kinda like opening 
envelopes in the mail room :) Disclaimer: This is what some 
networking guys told me in a presentation about 10 years ago.


In summary, ACH is safe if you do it from home without a proxy. Of 
course "safe" is relative, but it's safer than checks in the mail. 
Drop into your bank and ask the branch manager, or call their 
customer

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-07-04 Thread George Toft via PLUG-discuss


IMHO, Y'all are brave.

Regards,

George Toft

On 7/3/2024 11:31 PM, Steve Litt via PLUG-discuss wrote:

Keith Smith via PLUG-discuss said on Wed, 03 Jul 2024 06:21:25 -0700




On 2024-07-02 18:20, George Toft via PLUG-discuss wrote:

I work for a bank, and you would be amazed at how much security is
baked into the connecting your browser to their web servers. Makes
the NSA look like freshmen. And no, I'm not telling you who I work
for.

Regards,

George Toft

I'd like to hear more.  The world is a hostile place.  I recently went
old school.  I asked the bank to disarm my online banking.  I now deal
with paper statements and everything gets paid by check.  Not as
convenient as on-line banking, however I am hoping it makes my world a
little bit more secure.

I did the exact same thing decades ago.

SteveT

Steve Litt

http://444domains.com
---
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

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-07-04 Thread George Toft via PLUG-discuss




Regards,

George Toft

On 7/4/2024 6:50 AM, techli...@phpcoderusa.com wrote:

Thank you so much George!!

Another Question.  I was a police officer in the 80's and 90's. During 
my tenure the bank was on the hook for any criminal acts as long as 
the customer was not negligent. I only dealt with this on a couple 
occasional.


So If someone gets access to my online banking and I report it in a 
timely manner, or if someone washes one of my checks and I report it 
in a timely manner, is the bank on the hook or am I?


There are a ton of rules with more acronyms than the IT world has. I 
would love to tell you what I understand, but I'd be talking out my ass.



BTW I thought going old school was the most secure.  I do not trust 
the Internet.  My daily driver is a Linux Box and I do not use my 
cellular phone for anything except to talk and read some news.  I am 
semiretired and have home officed for a long time.


Not sure there is any magic incantation that I can say that would put 
you at ease, other than "Risk Analysis," "Government Regulation," "Audit 
and Reviews," "Compliance," "Controls and Countermeasures," and "Fines." 
We have to comply with a bazillion rules all designed to protect you, 
the bank customer. Some regions are really strict and their governments 
show they really care, like the EU - their rules are so restrictive. 
Here's an example: You cannot log into a server that serves the EU if 
Payment Card Information (PCI) is involved with the same user ID that 
you used to log into your work station. This prevents lateral movement 
from an insider attack should the attacker get an employee's credentials 
or Kerberos TGT (Hey!!! It's now on-topic!!!) . This is just an example. 
We have external inspectors and government auditors on site almost every 
two weeks making us prove compliance with all the rules, and the bigger 
we get, the more rules and more regulatory auditors we get to talk to. 
We actually have two people on my team of 27 whose job used to be 
project management, now is audit and compliance. All of this to protect you.


Let's not forget about the Security Operations Center monitoring 
employee activities. Refer to the GTFOBins email from yesterday. I 
documented a chained attack to get root based on that page, and the SOC 
came knocking saying "George, we noticed suspicious activity on this 
server and this date. Whatcha doin'?" Fortunately, I documented 
everything and emailed it to my manager, so all I had to do was forward 
that back to the SOC.


Mail scares me. I had to send my LEA ID in recently via USPS. I'm hoping 
they got it.




Any suggestions are appreciated.



On 2024-07-03 21:48, George Toft wrote:
Sorry, Kieth, I have bad news for you. You took a 30+ year leap 
backwards in security.


I can tell you for certain, from my bank fraud analyst friend (just 
got promoted to financial crimes investigator), checks are the second 
most insecure way of transferring money, first being putting the 
money in the envelope. They helped the USPS bust a fraud ring who 
worked in the Post Office - fraudsters were pulling checks out of 
envelopes inside the local Post Office. My friend pulled out all the 
details for the Postmaster General.


ACH is free (for you) and secure and guaranteed by the originator as 
they are on the hook to prove the identity of who initiated the 
transaction and they have to pay. It's all very complicated, and I'm 
not going into details here.


I use ACH all the time. My physical devices have multi-layer physical 
protection. Logical access control is in-place. Both have 
multi-factor authentication. Password resets require multi-factor 
authentication.


And the DoD is worse - their systems have so many layers, it was 
easier to just let my account get deleted from lack of use and 
rebuilt it from scratch. I have notes that tell me screen-by-screen 
what to put in each box and which ones to ignore. It's so secure, 
legitimate users can't even get in... and this is just my health 
insurance.


Where all of this can break down - getting on topic - is with the SSH 
protocol and web proxies. When you connect to a website using HTTPS 
using a web proxy, your web browser uses it's cert to set up the 
connection, or so it thinks. What's really happening is the proxy is 
responding to the request and decrypting the message, then it forms a 
new request and sends it to the bank, which believes the proxy and 
sends it back. Everything gets decrypted on the proxy, so whoever has 
admin access to the proxy can see everything. Kinda like opening 
envelopes in the mail room :) Disclaimer: This is what some 
networking guys told me in a presentation about 10 years ago.


In summary, ACH is safe if you do it from home without a proxy. Of 
course "safe" is relative, but it's safer than checks in the mail. 
Drop into your bank and ask the branch manager, or call their 
customer service and ask. They won't tell you checks are bad, but 
they will steer you to AC

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-07-04 Thread Michael via PLUG-discuss

you inspired me, rusty. thank you.

On Wed, Jul 3, 2024 at 4:00 PM rusty  wrote:

> 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 . 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.
>> >
>> >

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)


Thank you so much George!!

Another Question.  I was a police officer in the 80's and 90's.  During 
my tenure the bank was on the hook for any criminal acts as long as the 
customer was not negligent. I only dealt with this on a couple 
occasional.


So If someone gets access to my online banking and I report it in a 
timely manner, or if someone washes one of my checks and I report it in 
a timely manner, is the bank on the hook or am I?


BTW I thought going old school was the most secure.  I do not trust the 
Internet.  My daily driver is a Linux Box and I do not use my cellular 
phone for anything except to talk and read some news.  I am semiretired 
and have home officed for a long time.


Any suggestions are appreciated.



On 2024-07-03 21:48, George Toft wrote:
Sorry, Kieth, I have bad news for you. You took a 30+ year leap 
backwards in security.


I can tell you for certain, from my bank fraud analyst friend (just got 
promoted to financial crimes investigator), checks are the second most 
insecure way of transferring money, first being putting the money in 
the envelope. They helped the USPS bust a fraud ring who worked in the 
Post Office - fraudsters were pulling checks out of envelopes inside 
the local Post Office. My friend pulled out all the details for the 
Postmaster General.


ACH is free (for you) and secure and guaranteed by the originator as 
they are on the hook to prove the identity of who initiated the 
transaction and they have to pay. It's all very complicated, and I'm 
not going into details here.


I use ACH all the time. My physical devices have multi-layer physical 
protection. Logical access control is in-place. Both have multi-factor 
authentication. Password resets require multi-factor authentication.


And the DoD is worse - their systems have so many layers, it was easier 
to just let my account get deleted from lack of use and rebuilt it from 
scratch. I have notes that tell me screen-by-screen what to put in each 
box and which ones to ignore. It's so secure, legitimate users can't 
even get in... and this is just my health insurance.


Where all of this can break down - getting on topic - is with the SSH 
protocol and web proxies. When you connect to a website using HTTPS 
using a web proxy, your web browser uses it's cert to set up the 
connection, or so it thinks. What's really happening is the proxy is 
responding to the request and decrypting the message, then it forms a 
new request and sends it to the bank, which believes the proxy and 
sends it back. Everything gets decrypted on the proxy, so whoever has 
admin access to the proxy can see everything. Kinda like opening 
envelopes in the mail room :) Disclaimer: This is what some networking 
guys told me in a presentation about 10 years ago.


In summary, ACH is safe if you do it from home without a proxy. Of 
course "safe" is relative, but it's safer than checks in the mail. Drop 
into your bank and ask the branch manager, or call their customer 
service and ask. They won't tell you checks are bad, but they will 
steer you to ACH and tell you it's better. Break out the Rosetta Stone 
and figure out what "better" means in corporate-speak. Banks are in it 
to win it, and they don't offer something for free unless they are 
saving money (cost avoidance) on the alternatives.


Regards,

George Toft

On 7/3/2024 6:21 AM, techli...@phpcoderusa.com wrote:



On 2024-07-02 18:20, George Toft via PLUG-discuss wrote:
I work for a bank, and you would be amazed at how much security is 
baked into the connecting your browser to their web servers. Makes 
the NSA look like freshmen. And no, I'm not telling you who I work 
for.


Regards,

George Toft


I'd like to hear more.  The world is a hostile place.  I recently went 
old school.  I asked the bank to disarm my online banking.  I now deal 
with paper statements and everything gets paid by check. Not as 
convenient as on-line banking, however I am hoping it makes my world a 
little bit more secure.


What are your thoughts?

Keith







On 6/29/2024 5:19 PM, Keith Smith via PLUG-discuss wrote:

Mike,

The world is a hostile place.  The more precautions you take the 
better.  I cover the camera on my cellular phone while not in use.  
I cover the camera that is built into my laptop while it is not in 
use.  I think on-line banking is dangerous.  At some point I want to 
turn off WIFI and go to wired only on my local net.


We lock our cars and houses for a reason.

I do not know as much security as I'd like, however it might be 
necessary at some point to to become more cyber.


About 24 years ago the members of the Tucson Free Unix Group (TFUG) 
helped me build a server that I ran out of my home.  We left the 
email relay open and I got exploited.  About 10 years ago I became 
root and I accidentally overwrote my home directory. yikes... both 
were painful.  The first example is a reason we must be more aware 
of what we are doing. The 2nd is an example why we should u

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-07-04 Thread Ryan Petris via PLUG-discuss

> 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.

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.

> 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.

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.

I don't know of any examples off the top of my head, but there's also programs 
that *think* they need root but function just fine without it, in which case 
using fakeroot would be sufficient.

On Wed, Jul 3, 2024, at 10:47 PM, George Toft wrote:
> 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 
>  and then invokes the  binary>. In 99.9% of the cases over the last several years,  
> 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 . Side-by-side,

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-07-03 Thread Steve Litt via PLUG-discuss

Keith Smith via PLUG-discuss said on Wed, 03 Jul 2024 06:21:25 -0700

>
>
>On 2024-07-02 18:20, George Toft via PLUG-discuss wrote:
>> I work for a bank, and you would be amazed at how much security is 
>> baked into the connecting your browser to their web servers. Makes
>> the NSA look like freshmen. And no, I'm not telling you who I work
>> for.
>> 
>> Regards,
>> 
>> George Toft  
>
>I'd like to hear more.  The world is a hostile place.  I recently went 
>old school.  I asked the bank to disarm my online banking.  I now deal 
>with paper statements and everything gets paid by check.  Not as 
>convenient as on-line banking, however I am hoping it makes my world a 
>little bit more secure.

I did the exact same thing decades ago.

SteveT

Steve Litt 

http://444domains.com
---
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

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

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 
 and then invokes the 
. In 99.9% of the cases over the last several years, 
 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 . 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.

(O

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

Regards,

George Toft

On 7/3/2024 5:57 AM, techli...@phpcoderusa.com wrote:

On 2024-07-02 19:05, 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 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 tell us more, please.

https://nclalegal.org/wp-content/uploads/2022/09/Joint-Statement-on-Discovery-Disputes-Combined.pdf

search for "PageID #: 2793"

Other than to say Free Speech is like Free Software - must be cherished.
Whether the speech/software is useful is up to the consumer, not the
government.

End of Line.

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 yo

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

I did say "not naming vendor." Trade secret. We don't discuss our 
vendors. Sorry, Mike.

Regards,

George Toft

On 7/3/2024 4:37 AM, Michael via PLUG-discuss wrote:

can you share with usw what you use instead of sudo?

On Tue, Jul 2, 2024 at 11:42 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 . 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
> r

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

Sorry, Kieth, I have bad news for you. You took a 30+ year leap 
backwards in security.


I can tell you for certain, from my bank fraud analyst friend (just got 
promoted to financial crimes investigator), checks are the second most 
insecure way of transferring money, first being putting the money in the 
envelope. They helped the USPS bust a fraud ring who worked in the Post 
Office - fraudsters were pulling checks out of envelopes inside the 
local Post Office. My friend pulled out all the details for the 
Postmaster General.


ACH is free (for you) and secure and guaranteed by the originator as 
they are on the hook to prove the identity of who initiated the 
transaction and they have to pay. It's all very complicated, and I'm not 
going into details here.


I use ACH all the time. My physical devices have multi-layer physical 
protection. Logical access control is in-place. Both have multi-factor 
authentication. Password resets require multi-factor authentication.


And the DoD is worse - their systems have so many layers, it was easier 
to just let my account get deleted from lack of use and rebuilt it from 
scratch. I have notes that tell me screen-by-screen what to put in each 
box and which ones to ignore. It's so secure, legitimate users can't 
even get in... and this is just my health insurance.


Where all of this can break down - getting on topic - is with the SSH 
protocol and web proxies. When you connect to a website using HTTPS 
using a web proxy, your web browser uses it's cert to set up the 
connection, or so it thinks. What's really happening is the proxy is 
responding to the request and decrypting the message, then it forms a 
new request and sends it to the bank, which believes the proxy and sends 
it back. Everything gets decrypted on the proxy, so whoever has admin 
access to the proxy can see everything. Kinda like opening envelopes in 
the mail room :) Disclaimer: This is what some networking guys told me 
in a presentation about 10 years ago.


In summary, ACH is safe if you do it from home without a proxy. Of 
course "safe" is relative, but it's safer than checks in the mail. Drop 
into your bank and ask the branch manager, or call their customer 
service and ask. They won't tell you checks are bad, but they will steer 
you to ACH and tell you it's better. Break out the Rosetta Stone and 
figure out what "better" means in corporate-speak. Banks are in it to 
win it, and they don't offer something for free unless they are saving 
money (cost avoidance) on the alternatives.


Regards,

George Toft

On 7/3/2024 6:21 AM, techli...@phpcoderusa.com wrote:



On 2024-07-02 18:20, George Toft via PLUG-discuss wrote:
I work for a bank, and you would be amazed at how much security is 
baked into the connecting your browser to their web servers. Makes 
the NSA look like freshmen. And no, I'm not telling you who I work for.


Regards,

George Toft


I'd like to hear more.  The world is a hostile place.  I recently went 
old school.  I asked the bank to disarm my online banking.  I now deal 
with paper statements and everything gets paid by check. Not as 
convenient as on-line banking, however I am hoping it makes my world a 
little bit more secure.


What are your thoughts?

Keith







On 6/29/2024 5:19 PM, Keith Smith via PLUG-discuss wrote:

Mike,

The world is a hostile place.  The more precautions you take the 
better.  I cover the camera on my cellular phone while not in use.  
I cover the camera that is built into my laptop while it is not in 
use.  I think on-line banking is dangerous.  At some point I want to 
turn off WIFI and go to wired only on my local net.


We lock our cars and houses for a reason.

I do not know as much security as I'd like, however it might be 
necessary at some point to to become more cyber.


About 24 years ago the members of the Tucson Free Unix Group (TFUG) 
helped me build a server that I ran out of my home.  We left the 
email relay open and I got exploited.  About 10 years ago I became 
root and I accidentally overwrote my home directory. yikes... both 
were painful.  The first example is a reason we must be more aware 
of what we are doing. The 2nd is an example why we should use sudo 
as much as we can instead of becoming root.


Keith



On 2024-06-29 08:55, Michael via PLUG-discuss wrote:

I just realized, while 99% of the people on this list are honest there
is the diabolical 1%. So I guess I enter my password for the rest of
my life. Or do you think that it really matters considering this is
only a mailing list?

On Sat, Jun 29, 2024, 10:22 AM Michael  wrote:


Thanks for saying this. I realized that I only needed to run apt as
root. I didn't know how to make it so I could do that. but
chatgt did!

On Sat, Jun 29, 2024, 5:53 AM Eric Oyen via PLUG-discuss
 wrote:


NO WORRIES FROM THIS END RUSTY.

As a general rule, I use sudo only for very specific tasks
(usually updating my development package tree on OS X) and no
where else will I run

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-07-03 Thread Ryan Petris via PLUG-discuss

> 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 . 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

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-07-03 Thread rusty via PLUG-discuss

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 
 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 
> 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 . 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

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-07-03 Thread Keith Smith via PLUG-discuss




On 2024-07-02 18:20, George Toft via PLUG-discuss wrote:
I work for a bank, and you would be amazed at how much security is 
baked into the connecting your browser to their web servers. Makes the 
NSA look like freshmen. And no, I'm not telling you who I work for.


Regards,

George Toft


I'd like to hear more.  The world is a hostile place.  I recently went 
old school.  I asked the bank to disarm my online banking.  I now deal 
with paper statements and everything gets paid by check.  Not as 
convenient as on-line banking, however I am hoping it makes my world a 
little bit more secure.


What are your thoughts?

Keith







On 6/29/2024 5:19 PM, Keith Smith via PLUG-discuss wrote:

Mike,

The world is a hostile place.  The more precautions you take the 
better.  I cover the camera on my cellular phone while not in use.  I 
cover the camera that is built into my laptop while it is not in use.  
I think on-line banking is dangerous.  At some point I want to turn 
off WIFI and go to wired only on my local net.


We lock our cars and houses for a reason.

I do not know as much security as I'd like, however it might be 
necessary at some point to to become more cyber.


About 24 years ago the members of the Tucson Free Unix Group (TFUG) 
helped me build a server that I ran out of my home.  We left the email 
relay open and I got exploited.  About 10 years ago I became root and 
I accidentally overwrote my home directory. yikes... both were 
painful.  The first example is a reason we must be more aware of what 
we are doing. The 2nd is an example why we should use sudo as much as 
we can instead of becoming root.


Keith



On 2024-06-29 08:55, Michael via PLUG-discuss wrote:
I just realized, while 99% of the people on this list are honest 
there

is the diabolical 1%. So I guess I enter my password for the rest of
my life. Or do you think that it really matters considering this is
only a mailing list?

On Sat, Jun 29, 2024, 10:22 AM Michael  wrote:


Thanks for saying this. I realized that I only needed to run apt as
root. I didn't know how to make it so I could do that. but
chatgt did!

On Sat, Jun 29, 2024, 5:53 AM Eric Oyen via PLUG-discuss
 wrote:


NO WORRIES FROM THIS END RUSTY.

As a general rule, I use sudo only for very specific tasks
(usually updating my development package tree on OS X) and no
where else will I run anything as root. I have seen what happens
to linux machines that run infected binaries as root and it can
get ugly pretty fast. In one case, I couldn’t take the machine
out of service because of other items I was involved with, so I
simply made part of the dir tree immutable after replacing a few
files in /etc. That would fill up the system logs with an error
message about a specific binary trying to replace a small number
of conf files. Once the offending binary was found, it made things
easier trying to disable it or get rid of it. However, after a
while, I simply pulled the drive and ran it through a Dod secure
erase and installed a newer linux bistro on it. I did use the same
trick with chattr to make /bin, /sbin and /etc immutable. That
last turned out to be handy as I caught someone trying to rootkit
my machine using a known exploit, only they couldn’t get it to
run because the binaries they wanted to replace couldn’t be
written to. :)Yes, this would be a bit excessive, but over the
long run, proved far less inconvenient than having to wipe and
reinstall an OS.

-Eric
From the central Offices of the Technomage Guild, security
Applications Dept.


On Jun 28, 2024, at 6:43 PM, Rusty Carruth via PLUG-discuss

 wrote:


(Deep breath.  Calm...)

I can't figure out how to respond rationally to the below, so

all I'm going to say is - before you call troll,  you might want
to research the author, and read a bit more carefully what they
wrote.  I don't believe I recommended any of the crazy things you
suggest.  And I certainly didn't intend to imply any of that.


On the other hand, it may not have  been clear, so I'll just say

"Sorry that what I wrote wasn't clear, but english isn't my first
language.  Unfortunately its the only one I know".


And on that note, I'll shut up.

On 6/26/24 15:05, Ryan Petris wrote:

I feel like you're trolling so I'm not going to spend very much

time on this.


It's been a generally good security practice for at least the

last 25+ years to not regularly run as a privileged user,
requiring some sort of escalation to do administrative-type tasks.
By using passwordless sudo, you're taking away that escalation.
Why not just run as root? Then you don't need sudo at all. In
fact, why even have a password at all? Why encrypt? Why don't you
just put all your data on a publicly accessible FTP server and
just grab stuff when you need it? The NSA has all your data anyway
and you don't have anything to hide so why not just leave it out
there for the world to see?


As for something malicious needing to be written to use sudo,

why wouldn't it? sudo is ubiq

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-07-03 Thread Keith Smith via PLUG-discuss




On 2024-07-02 19:05, 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 . 
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 tell us more, please.





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 inf

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-07-03 Thread Michael via PLUG-discuss

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 . 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. (si

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-07-03 Thread Michael via PLUG-discuss

can you share with usw what you use instead of sudo?

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 . 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 actua

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-07-02 Thread George Toft via PLUG-discuss

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 . 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 t

Re: trouble adding my user to sudoers list

2024-07-02 Thread George Toft via PLUG-discuss


Agreed, but...

Your comment is what I've been telling writers and filmmakers for almost 
a year. However, AI can jog a few thoughts loose and inspire the human 
to new paths of success.


Regards,

George Toft

On 6/25/2024 10:04 PM, Eric Oyen via PLUG-discuss wrote:

Yeah, right!

Sorry, but AI in any form just won’t replace a human with any real 
experience.


-Eric
From the Central Offices of the Technomage Gild, Human Relations Dept.


On 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

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-07-02 Thread George Toft via PLUG-discuss

I work for a bank, and you would be amazed at how much security is baked 
into the connecting your browser to their web servers. Makes the NSA 
look like freshmen. And no, I'm not telling you who I work for.


Regards,

George Toft

On 6/29/2024 5:19 PM, Keith Smith via PLUG-discuss wrote:

Mike,

The world is a hostile place.  The more precautions you take the 
better.  I cover the camera on my cellular phone while not in use.  I 
cover the camera that is built into my laptop while it is not in use.  
I think on-line banking is dangerous.  At some point I want to turn 
off WIFI and go to wired only on my local net.


We lock our cars and houses for a reason.

I do not know as much security as I'd like, however it might be 
necessary at some point to to become more cyber.


About 24 years ago the members of the Tucson Free Unix Group (TFUG) 
helped me build a server that I ran out of my home.  We left the email 
relay open and I got exploited.  About 10 years ago I became root and 
I accidentally overwrote my home directory. yikes... both were 
painful.  The first example is a reason we must be more aware of what 
we are doing. The 2nd is an example why we should use sudo as much as 
we can instead of becoming root.


Keith



On 2024-06-29 08:55, Michael via PLUG-discuss wrote:

I just realized, while 99% of the people on this list are honest there
is the diabolical 1%. So I guess I enter my password for the rest of
my life. Or do you think that it really matters considering this is
only a mailing list?

On Sat, Jun 29, 2024, 10:22 AM Michael  wrote:


Thanks for saying this. I realized that I only needed to run apt as
root. I didn't know how to make it so I could do that. but
chatgt did!

On Sat, Jun 29, 2024, 5:53 AM Eric Oyen via PLUG-discuss
 wrote:


NO WORRIES FROM THIS END RUSTY.

As a general rule, I use sudo only for very specific tasks
(usually updating my development package tree on OS X) and no
where else will I run anything as root. I have seen what happens
to linux machines that run infected binaries as root and it can
get ugly pretty fast. In one case, I couldn’t take the machine
out of service because of other items I was involved with, so I
simply made part of the dir tree immutable after replacing a few
files in /etc. That would fill up the system logs with an error
message about a specific binary trying to replace a small number
of conf files. Once the offending binary was found, it made things
easier trying to disable it or get rid of it. However, after a
while, I simply pulled the drive and ran it through a Dod secure
erase and installed a newer linux bistro on it. I did use the same
trick with chattr to make /bin, /sbin and /etc immutable. That
last turned out to be handy as I caught someone trying to rootkit
my machine using a known exploit, only they couldn’t get it to
run because the binaries they wanted to replace couldn’t be
written to. :)Yes, this would be a bit excessive, but over the
long run, proved far less inconvenient than having to wipe and
reinstall an OS.

-Eric
From the central Offices of the Technomage Guild, security
Applications Dept.


On Jun 28, 2024, at 6:43 PM, Rusty Carruth via PLUG-discuss

 wrote:


(Deep breath.  Calm...)

I can't figure out how to respond rationally to the below, so

all I'm going to say is - before you call troll,  you might want
to research the author, and read a bit more carefully what they
wrote.  I don't believe I recommended any of the crazy things you
suggest.  And I certainly didn't intend to imply any of that.


On the other hand, it may not have  been clear, so I'll just say

"Sorry that what I wrote wasn't clear, but english isn't my first
language.  Unfortunately its the only one I know".


And on that note, I'll shut up.

On 6/26/24 15:05, Ryan Petris wrote:

I feel like you're trolling so I'm not going to spend very much

time on this.


It's been a generally good security practice for at least the

last 25+ years to not regularly run as a privileged user,
requiring some sort of escalation to do administrative-type tasks.
By using passwordless sudo, you're taking away that escalation.
Why not just run as root? Then you don't need sudo at all. In
fact, why even have a password at all? Why encrypt? Why don't you
just put all your data on a publicly accessible FTP server and
just grab stuff when you need it? The NSA has all your data anyway
and you don't have anything to hide so why not just leave it out
there for the world to see?


As for something malicious needing to be written to use sudo,

why wouldn't it? sudo is ubiquitous on unix systems; if it didn't
at least try then that seams like a pretty dumb malicious script
to me.


You also don't necessarily need to open/run something for it to

run. IIRC there was a recent image vulnerability in Gnome's
tracker-miner application which indexes files in your home
directory. And before you say that wouldn't happen in KDE, it too
has a similar program, I believe called Baloo.

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-06-30 Thread Rusty Carruth via PLUG-discuss



On 6/28/24 19:46, Ryan Petris wrote:

I didn't say that you *were* trolling, I said it *felt* like you were trolling. 
There's a small but non-insignificant difference there.

True, and apologies for taking it as a near-attack ;-)

Also, I'm not one to care for how credentialed someone may be -- so called 
professionals are wrong all the time. Nobody is perfect.
True as well, but I feel like if you've been around, and seen my 
postings (rare though they may be), and knew a bit more about me maybe 
you might not have even FELT like I was trolling.  Oh, well.

So let me expand on what I said earlier with a bit less sarcasm:

Yes, I was unable to get past the sarcasm


There are many different ways that something might end up executing on your 
computer that you didn't intend, especially with how advanced browsers are 
today. While most/all browsers today employ sandboxes, there have been and will 
be vulnerabilities to break out of said sandbox resulting in the ability to 
execute arbitrary code on your machine.

There have also been several supply-chain exploits within the last few years 
with npm and other package managers that are typically used by developers. One 
in particular targeted users in Russia and deleted files from their machines. I 
forget the details, but there was also something that happened with the 
acroread package in the Arch AUR a few years ago where a malicious actor took 
over the orphaned package and put something malicious in the PKGBUILD.

In all of those cases, while your data may have been affected, you could be 
certain that unless you typed in your password or that some other privilege 
escalation bug was employed, your system is safe, because the exploits would 
have been running with the context of your user. If you had passwordless 
escalation to root, however, then it's possible that said exploit did something 
to your system itself rather than just your home directory.

You could say that your data is more important than the system itself, and 
therefore it doesn't matter, and that's true for the data itself, but there's 
not really a way to secure your data without a secure system. So, to secure 
your data, you need to have a secure system, which is contrary to passwordless 
privilege escapation.

Now, the opinion above is passwordless sudo *in general for running arbitrary 
commands*. I agree that there are some commands you can give users access to 
that are otherwise benign yet need root permission to run. However, if an 
application is keeping up with the times, there are other ways to handle 
privilege escalation for just the things needed rather than running the entire 
application as root.


And you might find it incredible that I agree, passwordless sudo is, 
except in VERY small and totally contained situations, beyond foolish.  
As is running as root.  (As are a LOT of things we won't 'rabbit hole' 
on right now ;-)


However, that is absolutely NOT the only use for sudo, and I'm amazed 
that is, apparently, what people think its for.  (In fact, I'm almost 
speechless that this appears to be the assumed use of sudo.)


IMO, passwordless use of sudo is absolutely not the primary purpose (not 
even a very good purpose). The primary purpose for sudo is to allow the 
owners of a computer to have extremely fine control over who can do what 
administrative tasks, AND to allow simple, trivial, and much easier 
securing of a system when you fire the jerk... er, I mean the bad 
administrator ;-)  Assuming you are using some sort of centralized 
credential system, just disable that user and viola - all their 
passwords quit working, so they can not log in to your computers and 
they no longer have a password that gets them root.  Now, the truly 
paranoid (well, actually, the truly wise) would also immediately 
distribute a new sudoers file with that newly unemployeed admin removed 
from it.


Compare that with the situation when you give the admin the root 
password for the machine(s) they are administering.  Not only do you 
have to disable the user,  you have to change the root password on EVERY 
MACHINE they knew the password for, AND you have to distribute those new 
root passwords to all your admins!  And they call THAT more secure than 
sudo?  I don't get it  But on the other hand, if people have been 
framing the argument as 'passwordless sudo' versus 'su only', then


Ok, now I'll REALLY (try much harder to) shut up about this dead horse :-)


On Fri, Jun 28, 2024, at 6:43 PM, Rusty Carruth wrote:

(Deep breath.  Calm...)

I can't figure out how to respond rationally to the below, so all I'm
going to say is - before you call troll,  you might want to research the
author, and read a bit more carefully what they wrote.  I don't believe
I recommended any of the crazy things you suggest.  And I certainly
didn't intend to imply any of that.

On the other hand, it may not have  been clear, so I'll just say "Sorry
that what I wrote wasn't clear, but englis

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-06-30 Thread Michael via PLUG-discuss

Hey, I guess I need to change my username as well.

On Sun, Jun 30, 2024, 7:34 AM Michael  wrote:

> Yeah. That happened to me to a LONG time ago, too; now that I think about
> it.
>
> On Sat, Jun 29, 2024, 9:36 PM  wrote:
>
>> I have had several situations where I needed to become root because I
>> was unable to compete the task using sudo.  Maybe I do not
>> understand
>>
>>
>>
>> On 2024-06-29 19:05, Michael wrote:
>> > I thought using suddenly was the same as becoming root
>> >
>> > On Sat, Jun 29, 2024, 7:19 PM  wrote:
>> >
>> >> Mike,
>> >>
>> >> The world is a hostile place.  The more precautions you take the
>> >> better.
>> >> I cover the camera on my cellular phone while not in use.  I cover
>> >> the
>> >> camera that is built into my laptop while it is not in use.  I think
>> >>
>> >> on-line banking is dangerous.  At some point I want to turn off WIFI
>> >> and
>> >> go to wired only on my local net.
>> >>
>> >> We lock our cars and houses for a reason.
>> >>
>> >> I do not know as much security as I'd like, however it might be
>> >> necessary at some point to to become more cyber.
>> >>
>> >> About 24 years ago the members of the Tucson Free Unix Group (TFUG)
>> >> helped me build a server that I ran out of my home.  We left the
>> >> email
>> >> relay open and I got exploited.  About 10 years ago I became root
>> >> and I
>> >> accidentally overwrote my home directory.  yikes... both were
>> >> painful.
>> >> The first example is a reason we must be more aware of what we are
>> >> doing. The 2nd is an example why we should use sudo as much as we
>> >> can
>> >> instead of becoming root.
>> >>
>> >> Keith
>> >>
>> >> On 2024-06-29 08:55, Michael via PLUG-discuss wrote:
>> >>> I just realized, while 99% of the people on this list are honest
>> >> there
>> >>> is the diabolical 1%. So I guess I enter my password for the rest
>> >> of
>> >>> my life. Or do you think that it really matters considering this
>> >> is
>> >>> only a mailing list?
>> >>>
>> >>> On Sat, Jun 29, 2024, 10:22 AM Michael  wrote:
>> >>>
>>  Thanks for saying this. I realized that I only needed to run apt
>> >> as
>>  root. I didn't know how to make it so I could do that. but
>>  chatgt did!
>> 
>>  On Sat, Jun 29, 2024, 5:53 AM Eric Oyen via PLUG-discuss
>>   wrote:
>> 
>> > NO WORRIES FROM THIS END RUSTY.
>> >
>> > As a general rule, I use sudo only for very specific tasks
>> > (usually updating my development package tree on OS X) and no
>> > where else will I run anything as root. I have seen what happens
>> > to linux machines that run infected binaries as root and it can
>> > get ugly pretty fast. In one case, I couldn’t take the machine
>> > out of service because of other items I was involved with, so I
>> > simply made part of the dir tree immutable after replacing a few
>> > files in /etc. That would fill up the system logs with an error
>> > message about a specific binary trying to replace a small number
>> > of conf files. Once the offending binary was found, it made
>> >> things
>> > easier trying to disable it or get rid of it. However, after a
>> > while, I simply pulled the drive and ran it through a Dod secure
>> > erase and installed a newer linux bistro on it. I did use the
>> >> same
>> > trick with chattr to make /bin, /sbin and /etc immutable. That
>> > last turned out to be handy as I caught someone trying to
>> >> rootkit
>> > my machine using a known exploit, only they couldn’t get it to
>> > run because the binaries they wanted to replace couldn’t be
>> > written to. :)Yes, this would be a bit excessive, but over the
>> > long run, proved far less inconvenient than having to wipe and
>> > reinstall an OS.
>> >
>> > -Eric
>> > From the central Offices of the Technomage Guild, security
>> > Applications Dept.
>> >
>> >> On Jun 28, 2024, at 6:43 PM, Rusty Carruth via PLUG-discuss
>> >  wrote:
>> >>
>> >> (Deep breath.  Calm...)
>> >>
>> >> I can't figure out how to respond rationally to the below, so
>> > all I'm going to say is - before you call troll,  you might want
>> > to research the author, and read a bit more carefully what they
>> > wrote.  I don't believe I recommended any of the crazy things
>> >> you
>> > suggest.  And I certainly didn't intend to imply any of that.
>> >>
>> >> On the other hand, it may not have  been clear, so I'll just
>> >> say
>> > "Sorry that what I wrote wasn't clear, but english isn't my
>> >> first
>> > language.  Unfortunately its the only one I know".
>> >>
>> >> And on that note, I'll shut up.
>> >>
>> >> On 6/26/24 15:05, Ryan Petris wrote:
>> >>> I feel like you're trolling so I'm not going to spend very
>> >> much
>> > time on this.
>> >>>
>> >>> It's been a generally good security practice for at least the
>> > last 25+ years

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-06-30 Thread Michael via PLUG-discuss

Yeah. That happened to me to a LONG time ago, too; now that I think about
it.

On Sat, Jun 29, 2024, 9:36 PM  wrote:

> I have had several situations where I needed to become root because I
> was unable to compete the task using sudo.  Maybe I do not
> understand
>
>
>
> On 2024-06-29 19:05, Michael wrote:
> > I thought using suddenly was the same as becoming root
> >
> > On Sat, Jun 29, 2024, 7:19 PM  wrote:
> >
> >> Mike,
> >>
> >> The world is a hostile place.  The more precautions you take the
> >> better.
> >> I cover the camera on my cellular phone while not in use.  I cover
> >> the
> >> camera that is built into my laptop while it is not in use.  I think
> >>
> >> on-line banking is dangerous.  At some point I want to turn off WIFI
> >> and
> >> go to wired only on my local net.
> >>
> >> We lock our cars and houses for a reason.
> >>
> >> I do not know as much security as I'd like, however it might be
> >> necessary at some point to to become more cyber.
> >>
> >> About 24 years ago the members of the Tucson Free Unix Group (TFUG)
> >> helped me build a server that I ran out of my home.  We left the
> >> email
> >> relay open and I got exploited.  About 10 years ago I became root
> >> and I
> >> accidentally overwrote my home directory.  yikes... both were
> >> painful.
> >> The first example is a reason we must be more aware of what we are
> >> doing. The 2nd is an example why we should use sudo as much as we
> >> can
> >> instead of becoming root.
> >>
> >> Keith
> >>
> >> On 2024-06-29 08:55, Michael via PLUG-discuss wrote:
> >>> I just realized, while 99% of the people on this list are honest
> >> there
> >>> is the diabolical 1%. So I guess I enter my password for the rest
> >> of
> >>> my life. Or do you think that it really matters considering this
> >> is
> >>> only a mailing list?
> >>>
> >>> On Sat, Jun 29, 2024, 10:22 AM Michael  wrote:
> >>>
>  Thanks for saying this. I realized that I only needed to run apt
> >> as
>  root. I didn't know how to make it so I could do that. but
>  chatgt did!
> 
>  On Sat, Jun 29, 2024, 5:53 AM Eric Oyen via PLUG-discuss
>   wrote:
> 
> > NO WORRIES FROM THIS END RUSTY.
> >
> > As a general rule, I use sudo only for very specific tasks
> > (usually updating my development package tree on OS X) and no
> > where else will I run anything as root. I have seen what happens
> > to linux machines that run infected binaries as root and it can
> > get ugly pretty fast. In one case, I couldn’t take the machine
> > out of service because of other items I was involved with, so I
> > simply made part of the dir tree immutable after replacing a few
> > files in /etc. That would fill up the system logs with an error
> > message about a specific binary trying to replace a small number
> > of conf files. Once the offending binary was found, it made
> >> things
> > easier trying to disable it or get rid of it. However, after a
> > while, I simply pulled the drive and ran it through a Dod secure
> > erase and installed a newer linux bistro on it. I did use the
> >> same
> > trick with chattr to make /bin, /sbin and /etc immutable. That
> > last turned out to be handy as I caught someone trying to
> >> rootkit
> > my machine using a known exploit, only they couldn’t get it to
> > run because the binaries they wanted to replace couldn’t be
> > written to. :)Yes, this would be a bit excessive, but over the
> > long run, proved far less inconvenient than having to wipe and
> > reinstall an OS.
> >
> > -Eric
> > From the central Offices of the Technomage Guild, security
> > Applications Dept.
> >
> >> On Jun 28, 2024, at 6:43 PM, Rusty Carruth via PLUG-discuss
> >  wrote:
> >>
> >> (Deep breath.  Calm...)
> >>
> >> I can't figure out how to respond rationally to the below, so
> > all I'm going to say is - before you call troll,  you might want
> > to research the author, and read a bit more carefully what they
> > wrote.  I don't believe I recommended any of the crazy things
> >> you
> > suggest.  And I certainly didn't intend to imply any of that.
> >>
> >> On the other hand, it may not have  been clear, so I'll just
> >> say
> > "Sorry that what I wrote wasn't clear, but english isn't my
> >> first
> > language.  Unfortunately its the only one I know".
> >>
> >> And on that note, I'll shut up.
> >>
> >> On 6/26/24 15:05, Ryan Petris wrote:
> >>> I feel like you're trolling so I'm not going to spend very
> >> much
> > time on this.
> >>>
> >>> It's been a generally good security practice for at least the
> > last 25+ years to not regularly run as a privileged user,
> > requiring some sort of escalation to do administrative-type
> >> tasks.
> > By using passwordless sudo, you're taking away that escalation.
> > Why not just run as ro

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-06-29 Thread Keith Smith via PLUG-discuss

I have had several situations where I needed to become root because I 
was unable to compete the task using sudo.  Maybe I do not 
understand




On 2024-06-29 19:05, Michael wrote:

I thought using suddenly was the same as becoming root

On Sat, Jun 29, 2024, 7:19 PM  wrote:


Mike,

The world is a hostile place.  The more precautions you take the
better.
I cover the camera on my cellular phone while not in use.  I cover
the
camera that is built into my laptop while it is not in use.  I think

on-line banking is dangerous.  At some point I want to turn off WIFI
and
go to wired only on my local net.

We lock our cars and houses for a reason.

I do not know as much security as I'd like, however it might be
necessary at some point to to become more cyber.

About 24 years ago the members of the Tucson Free Unix Group (TFUG)
helped me build a server that I ran out of my home.  We left the
email
relay open and I got exploited.  About 10 years ago I became root
and I
accidentally overwrote my home directory.  yikes... both were
painful.
The first example is a reason we must be more aware of what we are
doing. The 2nd is an example why we should use sudo as much as we
can
instead of becoming root.

Keith

On 2024-06-29 08:55, Michael via PLUG-discuss wrote:

I just realized, while 99% of the people on this list are honest

there

is the diabolical 1%. So I guess I enter my password for the rest

of

my life. Or do you think that it really matters considering this

is

only a mailing list?

On Sat, Jun 29, 2024, 10:22 AM Michael  wrote:


Thanks for saying this. I realized that I only needed to run apt

as

root. I didn't know how to make it so I could do that. but
chatgt did!

On Sat, Jun 29, 2024, 5:53 AM Eric Oyen via PLUG-discuss
 wrote:


NO WORRIES FROM THIS END RUSTY.

As a general rule, I use sudo only for very specific tasks
(usually updating my development package tree on OS X) and no
where else will I run anything as root. I have seen what happens
to linux machines that run infected binaries as root and it can
get ugly pretty fast. In one case, I couldn’t take the machine
out of service because of other items I was involved with, so I
simply made part of the dir tree immutable after replacing a few
files in /etc. That would fill up the system logs with an error
message about a specific binary trying to replace a small number
of conf files. Once the offending binary was found, it made

things

easier trying to disable it or get rid of it. However, after a
while, I simply pulled the drive and ran it through a Dod secure
erase and installed a newer linux bistro on it. I did use the

same

trick with chattr to make /bin, /sbin and /etc immutable. That
last turned out to be handy as I caught someone trying to

rootkit

my machine using a known exploit, only they couldn’t get it to
run because the binaries they wanted to replace couldn’t be
written to. :)Yes, this would be a bit excessive, but over the
long run, proved far less inconvenient than having to wipe and
reinstall an OS.

-Eric
From the central Offices of the Technomage Guild, security
Applications Dept.


On Jun 28, 2024, at 6:43 PM, Rusty Carruth via PLUG-discuss

 wrote:


(Deep breath.  Calm...)

I can't figure out how to respond rationally to the below, so

all I'm going to say is - before you call troll,  you might want
to research the author, and read a bit more carefully what they
wrote.  I don't believe I recommended any of the crazy things

you

suggest.  And I certainly didn't intend to imply any of that.


On the other hand, it may not have  been clear, so I'll just

say

"Sorry that what I wrote wasn't clear, but english isn't my

first

language.  Unfortunately its the only one I know".


And on that note, I'll shut up.

On 6/26/24 15:05, Ryan Petris wrote:

I feel like you're trolling so I'm not going to spend very

much

time on this.


It's been a generally good security practice for at least the

last 25+ years to not regularly run as a privileged user,
requiring some sort of escalation to do administrative-type

tasks.

By using passwordless sudo, you're taking away that escalation.
Why not just run as root? Then you don't need sudo at all. In
fact, why even have a password at all? Why encrypt? Why don't

you

just put all your data on a publicly accessible FTP server and
just grab stuff when you need it? The NSA has all your data

anyway

and you don't have anything to hide so why not just leave it out
there for the world to see?


As for something malicious needing to be written to use sudo,

why wouldn't it? sudo is ubiquitous on unix systems; if it

didn't

at least try then that seams like a pretty dumb malicious script
to me.


You also don't necessarily need to open/run something for it

to

run. IIRC there was a recent image vulnerability in Gnome's
tracker-miner application which indexes files in your home
directory. And before you say that wouldn't happen in KDE, it

too

has a similar program, I believe called B

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

I thought using suddenly was the same as becoming root

On Sat, Jun 29, 2024, 7:19 PM  wrote:

> Mike,
>
> The world is a hostile place.  The more precautions you take the better.
>   I cover the camera on my cellular phone while not in use.  I cover the
> camera that is built into my laptop while it is not in use.  I think
> on-line banking is dangerous.  At some point I want to turn off WIFI and
> go to wired only on my local net.
>
> We lock our cars and houses for a reason.
>
> I do not know as much security as I'd like, however it might be
> necessary at some point to to become more cyber.
>
> About 24 years ago the members of the Tucson Free Unix Group (TFUG)
> helped me build a server that I ran out of my home.  We left the email
> relay open and I got exploited.  About 10 years ago I became root and I
> accidentally overwrote my home directory.  yikes... both were painful.
> The first example is a reason we must be more aware of what we are
> doing. The 2nd is an example why we should use sudo as much as we can
> instead of becoming root.
>
> Keith
>
>
>
> On 2024-06-29 08:55, Michael via PLUG-discuss wrote:
> > I just realized, while 99% of the people on this list are honest there
> > is the diabolical 1%. So I guess I enter my password for the rest of
> > my life. Or do you think that it really matters considering this is
> > only a mailing list?
> >
> > On Sat, Jun 29, 2024, 10:22 AM Michael  wrote:
> >
> >> Thanks for saying this. I realized that I only needed to run apt as
> >> root. I didn't know how to make it so I could do that. but
> >> chatgt did!
> >>
> >> On Sat, Jun 29, 2024, 5:53 AM Eric Oyen via PLUG-discuss
> >>  wrote:
> >>
> >>> NO WORRIES FROM THIS END RUSTY.
> >>>
> >>> As a general rule, I use sudo only for very specific tasks
> >>> (usually updating my development package tree on OS X) and no
> >>> where else will I run anything as root. I have seen what happens
> >>> to linux machines that run infected binaries as root and it can
> >>> get ugly pretty fast. In one case, I couldn’t take the machine
> >>> out of service because of other items I was involved with, so I
> >>> simply made part of the dir tree immutable after replacing a few
> >>> files in /etc. That would fill up the system logs with an error
> >>> message about a specific binary trying to replace a small number
> >>> of conf files. Once the offending binary was found, it made things
> >>> easier trying to disable it or get rid of it. However, after a
> >>> while, I simply pulled the drive and ran it through a Dod secure
> >>> erase and installed a newer linux bistro on it. I did use the same
> >>> trick with chattr to make /bin, /sbin and /etc immutable. That
> >>> last turned out to be handy as I caught someone trying to rootkit
> >>> my machine using a known exploit, only they couldn’t get it to
> >>> run because the binaries they wanted to replace couldn’t be
> >>> written to. :)Yes, this would be a bit excessive, but over the
> >>> long run, proved far less inconvenient than having to wipe and
> >>> reinstall an OS.
> >>>
> >>> -Eric
> >>> From the central Offices of the Technomage Guild, security
> >>> Applications Dept.
> >>>
>  On Jun 28, 2024, at 6:43 PM, Rusty Carruth via PLUG-discuss
> >>>  wrote:
> 
>  (Deep breath.  Calm...)
> 
>  I can't figure out how to respond rationally to the below, so
> >>> all I'm going to say is - before you call troll,  you might want
> >>> to research the author, and read a bit more carefully what they
> >>> wrote.  I don't believe I recommended any of the crazy things you
> >>> suggest.  And I certainly didn't intend to imply any of that.
> 
>  On the other hand, it may not have  been clear, so I'll just say
> >>> "Sorry that what I wrote wasn't clear, but english isn't my first
> >>> language.  Unfortunately its the only one I know".
> 
>  And on that note, I'll shut up.
> 
>  On 6/26/24 15:05, Ryan Petris wrote:
> > I feel like you're trolling so I'm not going to spend very much
> >>> time on this.
> >
> > It's been a generally good security practice for at least the
> >>> last 25+ years to not regularly run as a privileged user,
> >>> requiring some sort of escalation to do administrative-type tasks.
> >>> By using passwordless sudo, you're taking away that escalation.
> >>> Why not just run as root? Then you don't need sudo at all. In
> >>> fact, why even have a password at all? Why encrypt? Why don't you
> >>> just put all your data on a publicly accessible FTP server and
> >>> just grab stuff when you need it? The NSA has all your data anyway
> >>> and you don't have anything to hide so why not just leave it out
> >>> there for the world to see?
> >
> > As for something malicious needing to be written to use sudo,
> >>> why wouldn't it? sudo is ubiquitous on unix systems; if it didn't
> >>> at least try then that seams like a pretty dumb malicious script
> >>> to me.
> >
> > You also don't ne

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

2024-06-29 Thread Keith Smith via PLUG-discuss


Mike,

The world is a hostile place.  The more precautions you take the better. 
 I cover the camera on my cellular phone while not in use.  I cover the 
camera that is built into my laptop while it is not in use.  I think 
on-line banking is dangerous.  At some point I want to turn off WIFI and 
go to wired only on my local net.


We lock our cars and houses for a reason.

I do not know as much security as I'd like, however it might be 
necessary at some point to to become more cyber.


About 24 years ago the members of the Tucson Free Unix Group (TFUG) 
helped me build a server that I ran out of my home.  We left the email 
relay open and I got exploited.  About 10 years ago I became root and I 
accidentally overwrote my home directory.  yikes... both were painful.  
The first example is a reason we must be more aware of what we are 
doing. The 2nd is an example why we should use sudo as much as we can 
instead of becoming root.


Keith



On 2024-06-29 08:55, Michael via PLUG-discuss wrote:

I just realized, while 99% of the people on this list are honest there
is the diabolical 1%. So I guess I enter my password for the rest of
my life. Or do you think that it really matters considering this is
only a mailing list?

On Sat, Jun 29, 2024, 10:22 AM Michael  wrote:


Thanks for saying this. I realized that I only needed to run apt as
root. I didn't know how to make it so I could do that. but
chatgt did!

On Sat, Jun 29, 2024, 5:53 AM Eric Oyen via PLUG-discuss
 wrote:


NO WORRIES FROM THIS END RUSTY.

As a general rule, I use sudo only for very specific tasks
(usually updating my development package tree on OS X) and no
where else will I run anything as root. I have seen what happens
to linux machines that run infected binaries as root and it can
get ugly pretty fast. In one case, I couldn’t take the machine
out of service because of other items I was involved with, so I
simply made part of the dir tree immutable after replacing a few
files in /etc. That would fill up the system logs with an error
message about a specific binary trying to replace a small number
of conf files. Once the offending binary was found, it made things
easier trying to disable it or get rid of it. However, after a
while, I simply pulled the drive and ran it through a Dod secure
erase and installed a newer linux bistro on it. I did use the same
trick with chattr to make /bin, /sbin and /etc immutable. That
last turned out to be handy as I caught someone trying to rootkit
my machine using a known exploit, only they couldn’t get it to
run because the binaries they wanted to replace couldn’t be
written to. :)Yes, this would be a bit excessive, but over the
long run, proved far less inconvenient than having to wipe and
reinstall an OS.

-Eric
From the central Offices of the Technomage Guild, security
Applications Dept.


On Jun 28, 2024, at 6:43 PM, Rusty Carruth via PLUG-discuss

 wrote:


(Deep breath.  Calm...)

I can't figure out how to respond rationally to the below, so

all I'm going to say is - before you call troll,  you might want
to research the author, and read a bit more carefully what they
wrote.  I don't believe I recommended any of the crazy things you
suggest.  And I certainly didn't intend to imply any of that.


On the other hand, it may not have  been clear, so I'll just say

"Sorry that what I wrote wasn't clear, but english isn't my first
language.  Unfortunately its the only one I know".


And on that note, I'll shut up.

On 6/26/24 15:05, Ryan Petris wrote:

I feel like you're trolling so I'm not going to spend very much

time on this.


It's been a generally good security practice for at least the

last 25+ years to not regularly run as a privileged user,
requiring some sort of escalation to do administrative-type tasks.
By using passwordless sudo, you're taking away that escalation.
Why not just run as root? Then you don't need sudo at all. In
fact, why even have a password at all? Why encrypt? Why don't you
just put all your data on a publicly accessible FTP server and
just grab stuff when you need it? The NSA has all your data anyway
and you don't have anything to hide so why not just leave it out
there for the world to see?


As for something malicious needing to be written to use sudo,

why wouldn't it? sudo is ubiquitous on unix systems; if it didn't
at least try then that seams like a pretty dumb malicious script
to me.


You also don't necessarily need to open/run something for it to

run. IIRC there was a recent image vulnerability in Gnome's
tracker-miner application which indexes files in your home
directory. And before you say that wouldn't happen in KDE, it too
has a similar program, I believe called Baloo.


There also exists the recent doas program and the systemd

replacement run0 to do the same.


On Wed, Jun 26, 2024, at 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 t

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

Oh, am i remembering correctly that with scripts if you want to control
things you preface the command with 'username@computername'?
so assuming this I am safe again to allow sudo in the home-cage for apt.

On Sat, Jun 29, 2024, 11:00 AM Michael  wrote:

> Oh yeah. I changed my computer name.
>
> On Sat, Jun 29, 2024, 10:57 AM Michael  wrote:
>
>> And that it's only a home computer.
>>
>> On Sat, Jun 29, 2024, 10:55 AM Michael  wrote:
>>
>>> I just realized, while 99% of the people on this list are honest there
>>> is the diabolical 1%. So I guess I enter my password for the rest of my
>>> life. Or do you think that it really matters considering this is only a
>>> mailing list?
>>>
>>> On Sat, Jun 29, 2024, 10:22 AM Michael  wrote:
>>>
 Thanks for saying this. I realized that I only needed to run apt as
 root. I didn't know how to make it so I could do that. but chatgt did!

 On Sat, Jun 29, 2024, 5:53 AM Eric Oyen via PLUG-discuss <
 plug-discuss@lists.phxlinux.org> wrote:

> NO WORRIES FROM THIS END RUSTY.
>
> As a general rule, I use sudo only for very specific tasks (usually
> updating my development package tree on OS X) and no where else will I run
> anything as root. I have seen what happens to linux machines that run
> infected binaries as root and it can get ugly pretty fast. In one case, I
> couldn’t take the machine out of service because of other items I was
> involved with, so I simply made part of the dir tree immutable after
> replacing a few files in /etc. That would fill up the system logs with an
> error message about a specific binary trying to replace a small number of
> conf files. Once the offending binary was found, it made things easier
> trying to disable it or get rid of it. However, after a while, I simply
> pulled the drive and ran it through a Dod secure erase and installed a
> newer linux bistro on it. I did use the same trick with chattr to make
> /bin, /sbin and /etc immutable. That last turned out to be handy as I
> caught someone trying to rootkit my machine using a known exploit, only
> they couldn’t get it to run because the binaries they wanted to replace
> couldn’t be written to. :)Yes, this would be a bit excessive, but over the
> long run, proved far less inconvenient than having to wipe and reinstall 
> an
> OS.
>
> -Eric
> From the central Offices of the Technomage Guild, security
> Applications Dept.
>
>
> > On Jun 28, 2024, at 6:43 PM, Rusty Carruth via PLUG-discuss <
> plug-discuss@lists.phxlinux.org> wrote:
> >
> > (Deep breath.  Calm...)
> >
> > I can't figure out how to respond rationally to the below, so all
> I'm going to say is - before you call troll,  you might want to research
> the author, and read a bit more carefully what they wrote.  I don't 
> believe
> I recommended any of the crazy things you suggest.  And I certainly didn't
> intend to imply any of that.
> >
> > On the other hand, it may not have  been clear, so I'll just say
> "Sorry that what I wrote wasn't clear, but english isn't my first
> language.  Unfortunately its the only one I know".
> >
> > And on that note, I'll shut up.
> >
> > On 6/26/24 15:05, Ryan Petris wrote:
> >> I feel like you're trolling so I'm not going to spend very much
> time on this.
> >>
> >> It's been a generally good security practice for at least the last
> 25+ years to not regularly run as a privileged user, requiring some sort 
> of
> escalation to do administrative-type tasks. By using passwordless sudo,
> you're taking away that escalation. Why not just run as root? Then you
> don't need sudo at all. In fact, why even have a password at all? Why
> encrypt? Why don't you just put all your data on a publicly accessible FTP
> server and just grab stuff when you need it? The NSA has all your data
> anyway and you don't have anything to hide so why not just leave it out
> there for the world to see?
> >>
> >> As for something malicious needing to be written to use sudo, why
> wouldn't it? sudo is ubiquitous on unix systems; if it didn't at least try
> then that seams like a pretty dumb malicious script to me.
> >>
> >> You also don't necessarily need to open/run something for it to
> run. IIRC there was a recent image vulnerability in Gnome's tracker-miner
> application which indexes files in your home directory. And before you say
> that wouldn't happen in KDE, it too has a similar program, I believe 
> called
> Baloo.
> >>
> >> There also exists the recent doas program and the systemd
> replacement run0 to do the same.
> >>
> >> On Wed, Jun 26, 2024, at 12:23 PM, Rusty Carruth via PLUG-discuss
> wrote:
> >>> Actually, I'd like to start a bit of a discussion on this.
> >>>
> >

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

Oh yeah. I changed my computer name.

On Sat, Jun 29, 2024, 10:57 AM Michael  wrote:

> And that it's only a home computer.
>
> On Sat, Jun 29, 2024, 10:55 AM Michael  wrote:
>
>> I just realized, while 99% of the people on this list are honest there is
>> the diabolical 1%. So I guess I enter my password for the rest of my life.
>> Or do you think that it really matters considering this is only a mailing
>> list?
>>
>> On Sat, Jun 29, 2024, 10:22 AM Michael  wrote:
>>
>>> Thanks for saying this. I realized that I only needed to run apt as
>>> root. I didn't know how to make it so I could do that. but chatgt did!
>>>
>>> On Sat, Jun 29, 2024, 5:53 AM Eric Oyen via PLUG-discuss <
>>> plug-discuss@lists.phxlinux.org> wrote:
>>>
 NO WORRIES FROM THIS END RUSTY.

 As a general rule, I use sudo only for very specific tasks (usually
 updating my development package tree on OS X) and no where else will I run
 anything as root. I have seen what happens to linux machines that run
 infected binaries as root and it can get ugly pretty fast. In one case, I
 couldn’t take the machine out of service because of other items I was
 involved with, so I simply made part of the dir tree immutable after
 replacing a few files in /etc. That would fill up the system logs with an
 error message about a specific binary trying to replace a small number of
 conf files. Once the offending binary was found, it made things easier
 trying to disable it or get rid of it. However, after a while, I simply
 pulled the drive and ran it through a Dod secure erase and installed a
 newer linux bistro on it. I did use the same trick with chattr to make
 /bin, /sbin and /etc immutable. That last turned out to be handy as I
 caught someone trying to rootkit my machine using a known exploit, only
 they couldn’t get it to run because the binaries they wanted to replace
 couldn’t be written to. :)Yes, this would be a bit excessive, but over the
 long run, proved far less inconvenient than having to wipe and reinstall an
 OS.

 -Eric
 From the central Offices of the Technomage Guild, security Applications
 Dept.


 > On Jun 28, 2024, at 6:43 PM, Rusty Carruth via PLUG-discuss <
 plug-discuss@lists.phxlinux.org> wrote:
 >
 > (Deep breath.  Calm...)
 >
 > I can't figure out how to respond rationally to the below, so all I'm
 going to say is - before you call troll,  you might want to research the
 author, and read a bit more carefully what they wrote.  I don't believe I
 recommended any of the crazy things you suggest.  And I certainly didn't
 intend to imply any of that.
 >
 > On the other hand, it may not have  been clear, so I'll just say
 "Sorry that what I wrote wasn't clear, but english isn't my first
 language.  Unfortunately its the only one I know".
 >
 > And on that note, I'll shut up.
 >
 > On 6/26/24 15:05, Ryan Petris wrote:
 >> I feel like you're trolling so I'm not going to spend very much time
 on this.
 >>
 >> It's been a generally good security practice for at least the last
 25+ years to not regularly run as a privileged user, requiring some sort of
 escalation to do administrative-type tasks. By using passwordless sudo,
 you're taking away that escalation. Why not just run as root? Then you
 don't need sudo at all. In fact, why even have a password at all? Why
 encrypt? Why don't you just put all your data on a publicly accessible FTP
 server and just grab stuff when you need it? The NSA has all your data
 anyway and you don't have anything to hide so why not just leave it out
 there for the world to see?
 >>
 >> As for something malicious needing to be written to use sudo, why
 wouldn't it? sudo is ubiquitous on unix systems; if it didn't at least try
 then that seams like a pretty dumb malicious script to me.
 >>
 >> You also don't necessarily need to open/run something for it to run.
 IIRC there was a recent image vulnerability in Gnome's tracker-miner
 application which indexes files in your home directory. And before you say
 that wouldn't happen in KDE, it too has a similar program, I believe called
 Baloo.
 >>
 >> There also exists the recent doas program and the systemd
 replacement run0 to do the same.
 >>
 >> On Wed, Jun 26, 2024, at 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

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

And that it's only a home computer.

On Sat, Jun 29, 2024, 10:55 AM Michael  wrote:

> I just realized, while 99% of the people on this list are honest there is
> the diabolical 1%. So I guess I enter my password for the rest of my life.
> Or do you think that it really matters considering this is only a mailing
> list?
>
> On Sat, Jun 29, 2024, 10:22 AM Michael  wrote:
>
>> Thanks for saying this. I realized that I only needed to run apt as root.
>> I didn't know how to make it so I could do that. but chatgt did!
>>
>> On Sat, Jun 29, 2024, 5:53 AM Eric Oyen via PLUG-discuss <
>> plug-discuss@lists.phxlinux.org> wrote:
>>
>>> NO WORRIES FROM THIS END RUSTY.
>>>
>>> As a general rule, I use sudo only for very specific tasks (usually
>>> updating my development package tree on OS X) and no where else will I run
>>> anything as root. I have seen what happens to linux machines that run
>>> infected binaries as root and it can get ugly pretty fast. In one case, I
>>> couldn’t take the machine out of service because of other items I was
>>> involved with, so I simply made part of the dir tree immutable after
>>> replacing a few files in /etc. That would fill up the system logs with an
>>> error message about a specific binary trying to replace a small number of
>>> conf files. Once the offending binary was found, it made things easier
>>> trying to disable it or get rid of it. However, after a while, I simply
>>> pulled the drive and ran it through a Dod secure erase and installed a
>>> newer linux bistro on it. I did use the same trick with chattr to make
>>> /bin, /sbin and /etc immutable. That last turned out to be handy as I
>>> caught someone trying to rootkit my machine using a known exploit, only
>>> they couldn’t get it to run because the binaries they wanted to replace
>>> couldn’t be written to. :)Yes, this would be a bit excessive, but over the
>>> long run, proved far less inconvenient than having to wipe and reinstall an
>>> OS.
>>>
>>> -Eric
>>> From the central Offices of the Technomage Guild, security Applications
>>> Dept.
>>>
>>>
>>> > On Jun 28, 2024, at 6:43 PM, Rusty Carruth via PLUG-discuss <
>>> plug-discuss@lists.phxlinux.org> wrote:
>>> >
>>> > (Deep breath.  Calm...)
>>> >
>>> > I can't figure out how to respond rationally to the below, so all I'm
>>> going to say is - before you call troll,  you might want to research the
>>> author, and read a bit more carefully what they wrote.  I don't believe I
>>> recommended any of the crazy things you suggest.  And I certainly didn't
>>> intend to imply any of that.
>>> >
>>> > On the other hand, it may not have  been clear, so I'll just say
>>> "Sorry that what I wrote wasn't clear, but english isn't my first
>>> language.  Unfortunately its the only one I know".
>>> >
>>> > And on that note, I'll shut up.
>>> >
>>> > On 6/26/24 15:05, Ryan Petris wrote:
>>> >> I feel like you're trolling so I'm not going to spend very much time
>>> on this.
>>> >>
>>> >> It's been a generally good security practice for at least the last
>>> 25+ years to not regularly run as a privileged user, requiring some sort of
>>> escalation to do administrative-type tasks. By using passwordless sudo,
>>> you're taking away that escalation. Why not just run as root? Then you
>>> don't need sudo at all. In fact, why even have a password at all? Why
>>> encrypt? Why don't you just put all your data on a publicly accessible FTP
>>> server and just grab stuff when you need it? The NSA has all your data
>>> anyway and you don't have anything to hide so why not just leave it out
>>> there for the world to see?
>>> >>
>>> >> As for something malicious needing to be written to use sudo, why
>>> wouldn't it? sudo is ubiquitous on unix systems; if it didn't at least try
>>> then that seams like a pretty dumb malicious script to me.
>>> >>
>>> >> You also don't necessarily need to open/run something for it to run.
>>> IIRC there was a recent image vulnerability in Gnome's tracker-miner
>>> application which indexes files in your home directory. And before you say
>>> that wouldn't happen in KDE, it too has a similar program, I believe called
>>> Baloo.
>>> >>
>>> >> There also exists the recent doas program and the systemd replacement
>>> run0 to do the same.
>>> >>
>>> >> On Wed, Jun 26, 2024, at 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) f

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)

I just realized, while 99% of the people on this list are honest there is
the diabolical 1%. So I guess I enter my password for the rest of my life.
Or do you think that it really matters considering this is only a mailing
list?

On Sat, Jun 29, 2024, 10:22 AM Michael  wrote:

> Thanks for saying this. I realized that I only needed to run apt as root.
> I didn't know how to make it so I could do that. but chatgt did!
>
> On Sat, Jun 29, 2024, 5:53 AM Eric Oyen via PLUG-discuss <
> plug-discuss@lists.phxlinux.org> wrote:
>
>> NO WORRIES FROM THIS END RUSTY.
>>
>> As a general rule, I use sudo only for very specific tasks (usually
>> updating my development package tree on OS X) and no where else will I run
>> anything as root. I have seen what happens to linux machines that run
>> infected binaries as root and it can get ugly pretty fast. In one case, I
>> couldn’t take the machine out of service because of other items I was
>> involved with, so I simply made part of the dir tree immutable after
>> replacing a few files in /etc. That would fill up the system logs with an
>> error message about a specific binary trying to replace a small number of
>> conf files. Once the offending binary was found, it made things easier
>> trying to disable it or get rid of it. However, after a while, I simply
>> pulled the drive and ran it through a Dod secure erase and installed a
>> newer linux bistro on it. I did use the same trick with chattr to make
>> /bin, /sbin and /etc immutable. That last turned out to be handy as I
>> caught someone trying to rootkit my machine using a known exploit, only
>> they couldn’t get it to run because the binaries they wanted to replace
>> couldn’t be written to. :)Yes, this would be a bit excessive, but over the
>> long run, proved far less inconvenient than having to wipe and reinstall an
>> OS.
>>
>> -Eric
>> From the central Offices of the Technomage Guild, security Applications
>> Dept.
>>
>>
>> > On Jun 28, 2024, at 6:43 PM, Rusty Carruth via PLUG-discuss <
>> plug-discuss@lists.phxlinux.org> wrote:
>> >
>> > (Deep breath.  Calm...)
>> >
>> > I can't figure out how to respond rationally to the below, so all I'm
>> going to say is - before you call troll,  you might want to research the
>> author, and read a bit more carefully what they wrote.  I don't believe I
>> recommended any of the crazy things you suggest.  And I certainly didn't
>> intend to imply any of that.
>> >
>> > On the other hand, it may not have  been clear, so I'll just say "Sorry
>> that what I wrote wasn't clear, but english isn't my first language.
>> Unfortunately its the only one I know".
>> >
>> > And on that note, I'll shut up.
>> >
>> > On 6/26/24 15:05, Ryan Petris wrote:
>> >> I feel like you're trolling so I'm not going to spend very much time
>> on this.
>> >>
>> >> It's been a generally good security practice for at least the last 25+
>> years to not regularly run as a privileged user, requiring some sort of
>> escalation to do administrative-type tasks. By using passwordless sudo,
>> you're taking away that escalation. Why not just run as root? Then you
>> don't need sudo at all. In fact, why even have a password at all? Why
>> encrypt? Why don't you just put all your data on a publicly accessible FTP
>> server and just grab stuff when you need it? The NSA has all your data
>> anyway and you don't have anything to hide so why not just leave it out
>> there for the world to see?
>> >>
>> >> As for something malicious needing to be written to use sudo, why
>> wouldn't it? sudo is ubiquitous on unix systems; if it didn't at least try
>> then that seams like a pretty dumb malicious script to me.
>> >>
>> >> You also don't necessarily need to open/run something for it to run.
>> IIRC there was a recent image vulnerability in Gnome's tracker-miner
>> application which indexes files in your home directory. And before you say
>> that wouldn't happen in KDE, it too has a similar program, I believe called
>> Baloo.
>> >>
>> >> There also exists the recent doas program and the systemd replacement
>> run0 to do the same.
>> >>
>> >> On Wed, Jun 26, 2024, at 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

Re: sudo in general, and not requiring password in particular (was Re: trouble adding my user to sudoers list)