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

Mon, 08 Jul 2024 11:47:31 -0700 


Regards,

George Toft

On 7/5/2024 5:43 AM, [email protected] wrote:




On 2024-07-05 00:23, George Toft wrote:
Had a chance to casually ask about the washed check thing today. Big eye-roll. Police report. Affidavits. Close the checking account. Big investigation. Sounds like a PITA. 

Regards,

George Toft
I just want to approach this in a way that I have reasonably safe bank transactions.  I almost feel I need to learn cyber security. 

Thank you for all your feedback!!
BINGO!!! "Reasonably safe" is the fundamental goal post that we seek. What is one's risk appetite for any endeavor? There is no such thing as 0% loss. Obviously 100% loss is a non-starter. So somewhere in between is our goal. I won't beleaguer the list anymore, but this is the fundamentals of risk analysis, which is what I do at work. An on-topic example: In the not-Sudo solution we have, we discovered one application that would not work with it. One app - 6 servers out of 50,000 servers. Do I risk the 50,000 servers to make not-Sudo work on 6 when the original configurator made a fundamental programming error? No - we accept the risk. Actually, I'm now stuck with that misconfiguration without executing a ton of regression testing which would take months just to distill a reasonable test set, and my management isn't going to support spending thousands of salary dollars on something this trivial.
Lastly, the 7 banks that own Zelle are getting hauled in to talk to Congress about their "acceptable fraud rate." They cheerfully announce they have less than 0.1% fraud rate. These huge banks don't care about 0.1% - that's acceptable. But if 0.1% of all e-mail you receive got through the filters and infected your system, that becomes another story. 

Peace.









On 7/4/2024 3:14 PM, [email protected] wrote:

Thanks George!!  Lot s to think about.


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

<scroll>

Regards,

George Toft

On 7/4/2024 6:50 AM, [email protected] 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 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, [email protected] wrote:

<scroll>

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 <[email protected]> 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
<[email protected]> 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

<[email protected]> 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 well worth the price of admission, PLUS I 
can only

allow certain admins to run certain programs? Very nice.
So, for example, at my last place I allowed the 'tester' user 
to run
fdisk as root, because they needed to partition the disk under 
test.  In

my case, and since the network that we ran on was totally

isolated from

the corporate network, I let fdisk be run without needing a

password.
Oh, and if they messed up and fdisk'ed the boot partition, it 
was no big

deal - I could recreate the machine from scratch (minus

whatever data

hadn't been copied off yet - which would only be their most

recent run),

in 10 minutes (which was about 2 minutes of my time, and 8

minutes of
scripted 'dd' ;-) However, if the test user wanted to become 
root using

su, they had to enter the test user password.

So, back to the original question - setting sudo to not

require a
password.  We should have asked, what program do you want to 
run as root
without requiring a password? How secure is your system? What 
else do

you use it for? Who has access?  etc, etc, etc.
There's one other minor objection I have to the 'zero defense' 
statement
below - the malicious thing you downloaded (and, I assume ran) 
has to be
written to USE sudo in its attempt to break in, I believe, or 
it
wouldn't matter HOW open your sudo was. (simply saying 'su - 
myscript'

won't do it).

And, if you're truly paranoid about stuff you download, you

should:


1 - NEVER download something you don't have an excellent

reason to

believe is 'safe', and ALWAYS make sure you actually

downloaded it from

where you thought you did.
2 - For the TRULY paranoid, have a machine you use to download 
and test

software on, which you can totally disconnect from your

network (not

JUST the internet), and which has NO confidential info, and

which you

can erase and rebuild without caring.  Run the downloaded

stuff there,
for a long time, until you're pretty sure it won't bite you. 

3 - For the REALLY REALLY paranoid, don't download anything

from

anywhere, disconnect from the internet permanently, get

high-tech locks

for your doors, and wrap your house in a faraday cage!

And probably don't leave the house....

The point of number 3 is that there is always a risk, even

with

'well-known' software, and as someone else said - they're

watching you
anyway.  The question is how 'safe' do you want to be? And how 
paranoid

are you, really?

Wow, talk about rabbit hole! ;-)

'Let the flames begin!' :-)


On 6/25/24 18:50, Ryan Petris via PLUG-discuss wrote:

wanted sudo not to require a password.
Please reconsider this... This is VERY BAD security practice. 
There's basically zero defense if you happen to download/run
something malicious.


On Tue, Jun 25, 2024, at 6:01 PM, Michael via PLUG-discuss

wrote:
then I remember that a PLUG member mentioned ChatGPT being
good at troubleshooting so I figured I'd give it a go. I sprint about half an hour asking it the wrong question but after that it 
took 2 minutes. I wanted sudo not to require a password. it is
wonderful! now I don't have to bug you guys. so it looks like this 
is the end of the user group unless you want to talk about OT
stuff.


-- :-)~MIKE~(-:
---------------------------------------------------
PLUG-discuss mailing list: [email protected] To subscribe, unsubscribe, or to change your mail settings: 
https://lists.phxlinux.org/mailman/listinfo/plug-discuss


---------------------------------------------------
PLUG-discuss mailing list: [email protected]
To subscribe, unsubscribe, or to change your mail settings: 
https://lists.phxlinux.org/mailman/listinfo/plug-discuss

---------------------------------------------------
PLUG-discuss mailing list: [email protected]
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss


---------------------------------------------------
PLUG-discuss mailing list: [email protected]
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss


---------------------------------------------------
PLUG-discuss mailing list: [email protected]
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss

---------------------------------------------------
PLUG-discuss mailing list: [email protected]
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss

---------------------------------------------------
PLUG-discuss mailing list: [email protected]
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss

---------------------------------------------------
PLUG-discuss mailing list: [email protected]
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss

---------------------------------------------------
PLUG-discuss mailing list: [email protected]
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss

Reply via email to