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 <
bmike1@gmail.com> wrote:
> Oh yeah. I changed my computer name.
>
> On Sat, Jun 29, 2024, 10:57 AM Michael <bmike1@gmail.com> wrote:
>
>> And that it's only a home computer.
>>
>> On Sat, Jun 29, 2024, 10:55 AM Michael <bmike1@gmail.com> 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 <bmike1@gmail.com> 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
>>>>>
>>>>
---------------------------------------------------
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
(text/plain)