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. >>>>> >>> >>>>> >>> >>>>> >>> First, I know that for some reason RedHat seems to think that sudo >>>>> is >>>>> >>> bad/insecure. >>>>> >>> >>>>> >>> I'd like to know the logic there, as I think the argument FOR >>>>> using sudo >>>>> >>> is MUCH stronger than any argument I've heard (which, admittedly, >>>>> is >>>>> >>> pretty close to zero) AGAINST it. Here's my thinking: >>>>> >>> >>>>> >>> Allowing users to become root via sudo gives you: >>>>> >>> >>>>> >>> - VERY fine control over what programs a user can use as root >>>>> >>> >>>>> >>> - The ability to remove admin privs (ability to run as root) from >>>>> an >>>>> >>> individual WITHOUT having to change root password everywhere. >>>>> >>> >>>>> >>> Now, remember, RH is supposedly 'corporate friendly'. As a >>>>> corporation, >>>>> >>> that 2nd feature is well worth the price of admission, PLUS I can >>>>> only >>>>> >>> allow certain admins to run certain programs? Very nice. >>>>> >>> >>>>> >>> So, for example, at my last place I allowed the 'tester' user to >>>>> run >>>>> >>> fdisk as root, because they needed to partition the disk under >>>>> test. In >>>>> >>> my case, and since the network that we ran on was totally isolated >>>>> from >>>>> >>> the corporate network, I let fdisk be run without needing a >>>>> password. >>>>> >>> Oh, and if they messed up and fdisk'ed the boot partition, it was >>>>> no big >>>>> >>> deal - I could recreate the machine from scratch (minus whatever >>>>> data >>>>> >>> hadn't been copied off yet - which would only be their most recent >>>>> run), >>>>> >>> in 10 minutes (which was about 2 minutes of my time, and 8 minutes >>>>> of >>>>> >>> scripted 'dd' ;-) However, if the test user wanted to become root >>>>> using >>>>> >>> su, they had to enter the test user password. >>>>> >>> >>>>> >>> So, back to the original question - setting sudo to not require a >>>>> >>> password. We should have asked, what program do you want to run >>>>> as root >>>>> >>> without requiring a password? How secure is your system? What >>>>> else do >>>>> >>> you use it for? Who has access? etc, etc, etc. >>>>> >>> >>>>> >>> There's one other minor objection I have to the 'zero defense' >>>>> statement >>>>> >>> below - the malicious thing you downloaded (and, I assume ran) has >>>>> to be >>>>> >>> written to USE sudo in its attempt to break in, I believe, or it >>>>> >>> wouldn't matter HOW open your sudo was. (simply saying 'su - >>>>> myscript' >>>>> >>> won't do it). >>>>> >>> >>>>> >>> And, if you're truly paranoid about stuff you download, you should: >>>>> >>> >>>>> >>> 1 - NEVER download something you don't have an excellent reason to >>>>> >>> believe is 'safe', and ALWAYS make sure you actually downloaded it >>>>> from >>>>> >>> where you thought you did. >>>>> >>> >>>>> >>> 2 - For the TRULY paranoid, have a machine you use to download and >>>>> test >>>>> >>> software on, which you can totally disconnect from your network >>>>> (not >>>>> >>> JUST the internet), and which has NO confidential info, and which >>>>> you >>>>> >>> can erase and rebuild without caring. Run the downloaded stuff >>>>> there, >>>>> >>> for a long time, until you're pretty sure it won't bite you. >>>>> >>> >>>>> >>> 3 - For the REALLY REALLY paranoid, don't download anything from >>>>> >>> anywhere, disconnect from the internet permanently, get high-tech >>>>> locks >>>>> >>> for your doors, and wrap your house in a faraday cage! >>>>> >>> >>>>> >>> And probably don't leave the house.... >>>>> >>> >>>>> >>> The point of number 3 is that there is always a risk, even with >>>>> >>> 'well-known' software, and as someone else said - they're watching >>>>> you >>>>> >>> anyway. The question is how 'safe' do you want to be? And how >>>>> paranoid >>>>> >>> are you, really? >>>>> >>> >>>>> >>> Wow, talk about rabbit hole! ;-) >>>>> >>> >>>>> >>> 'Let the flames begin!' :-) >>>>> >>> >>>>> >>> >>>>> >>> On 6/25/24 18:50, Ryan Petris via PLUG-discuss wrote: >>>>> >>>>> wanted sudo not to require a password. >>>>> >>>> Please reconsider this... This is VERY BAD security practice. >>>>> There's basically zero defense if you happen to download/run something >>>>> malicious. >>>>> >>>> >>>>> >>>> On Tue, Jun 25, 2024, at 6:01 PM, Michael via PLUG-discuss wrote: >>>>> >>>>> then I remember that a PLUG member mentioned ChatGPT being >>>>> good at troubleshooting so I figured I'd give it a go. I sprint about half >>>>> an hour asking it the wrong question but after that it took 2 minutes. I >>>>> wanted sudo not to require a password. it is wonderful! now I don't have to >>>>> bug you guys. so it looks like this is the end of the user group unless you >>>>> want to talk about OT stuff. >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> :-)~MIKE~(-: >>>>> >>>>> --------------------------------------------------- >>>>> >>>>> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org >>>>> >>>>> To subscribe, unsubscribe, or to change your mail settings: >>>>> >>>>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss >>>>> >>>>> >>>>> >>>> --------------------------------------------------- >>>>> >>>> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org >>>>> >>>> To subscribe, unsubscribe, or to change your mail settings: >>>>> >>>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss >>>>> >>> --------------------------------------------------- >>>>> >>> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org >>>>> >>> To subscribe, unsubscribe, or to change your mail settings: >>>>> >>> https://lists.phxlinux.org/mailman/listinfo/plug-discuss >>>>> >>> >>>>> > --------------------------------------------------- >>>>> > PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org >>>>> > To subscribe, unsubscribe, or to change your mail settings: >>>>> > https://lists.phxlinux.org/mailman/listinfo/plug-discuss >>>>> >>>>> --------------------------------------------------- >>>>> 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 >>>>> >>>>