> 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 > <vendor product binary that shall not be named> and then invokes the <vendor > binary>. In 99.9% of the cases over the last several years, <vendor product> > 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 <unnamed product>. Side-by-side, >>> feature-by-feature, I did so, based on our POC's on Red Hat Identity >>> Manager (IdM), which uses sudo, and locally engineered solutions. >>> >>> I personally detest sudo because it's like chmod 777 * - makes >>> everything work so much better, and software vendors can just drop in >>> their own sudo rules in /etc/sudoers.d/ and make magic happen without >>> you ever knowing what happened. Several times we've had to convert some >>> vendor's sudo rules to our own system's rules, and I ask the vendor "Why >>> do you have this rule?" Their answer: "We don't know." OFFS :( >>> >>> As far as sudo goes, it is included in the Center for Internet >>> Security's (CIS) Benchmarks, which is the embodiment of the information >>> security industry's best practices. I did some work for them for a >>> couple years, and every change (add/mod/delete) required consensus >>> approval from 80 organizations around the world, including thee letter >>> agencies in the US and abroad. Many/most auditors expect financial >>> institutions to follow this guide, or explain convincingly why not. So >>> every six months, we get to say: "We don't use sudo. Instead, we do >>> this." And then we get to do live demos of timed privileged access. >>> Haven't had a follow-on question in the last 8 years. >>> >>> (OT: I cringe at referring to CIS because of their collusion with the >>> Arizona Secretary of State and the Department of Homeland Security to >>> suppress people's First Amendment Right to Free Speech. Proof is in the >>> Elon Musk Twitter Dump. I do not have a copy of the email on my >>> computer. I generally don't tell people I did work for them - it's so >>> embarrassing. Effing Ratbastards.) >>> >>> So... back to the original question, as I was not able to find anything >>> saying Red Hat discourages sudo, nor was my favorite AI. Please toss me >>> a cookie... >>> >>> Regards, >>> >>> George Toft >>> >>> On 6/26/2024 12:23 PM, Rusty Carruth via PLUG-discuss wrote: >>> > Actually, I'd like to start a bit of a discussion on this. >>> > >>> > >>> > First, I know that for some reason RedHat seems to think that sudo is >>> > bad/insecure. >>> > >>> > I'd like to know the logic there, as I think the argument FOR using >>> > sudo is MUCH stronger than any argument I've heard (which, admittedly, >>> > is pretty close to zero) AGAINST it. Here's my thinking: >>> > >>> > Allowing users to become root via sudo gives you: >>> > >>> > - VERY fine control over what programs a user can use as root >>> > >>> > - The ability to remove admin privs (ability to run as root) from an >>> > individual WITHOUT having to change root password everywhere. >>> > >>> > Now, remember, RH is supposedly 'corporate friendly'. As a >>> > corporation, that 2nd feature is well worth the price of admission, >>> > PLUS I can only allow certain admins to run certain programs? Very nice. >>> > >>> > So, for example, at my last place I allowed the 'tester' user to run >>> > fdisk as root, because they needed to partition the disk under test. >>> > In my case, and since the network that we ran on was totally isolated >>> > from the corporate network, I let fdisk be run without needing a >>> > password. Oh, and if they messed up and fdisk'ed the boot partition, >>> > it was no big deal - I could recreate the machine from scratch (minus >>> > whatever data hadn't been copied off yet - which would only be their >>> > most recent run), in 10 minutes (which was about 2 minutes of my time, >>> > and 8 minutes of scripted 'dd' ;-) However, if the test user wanted >>> > to become root using su, they had to enter the test user password. >>> > >>> > So, back to the original question - setting sudo to not require a >>> > password. We should have asked, what program do you want to run as >>> > root without requiring a password? How secure is your system? What >>> > else do you use it for? Who has access? etc, etc, etc. >>> > >>> > There's one other minor objection I have to the 'zero defense' >>> > statement below - the malicious thing you downloaded (and, I assume >>> > ran) has to be written to USE sudo in its attempt to break in, I >>> > believe, or it wouldn't matter HOW open your sudo was. (simply saying >>> > 'su - myscript' won't do it). >>> > >>> > And, if you're truly paranoid about stuff you download, you should: >>> > >>> > 1 - NEVER download something you don't have an excellent reason to >>> > believe is 'safe', and ALWAYS make sure you actually downloaded it >>> > from where you thought you did. >>> > >>> > 2 - For the TRULY paranoid, have a machine you use to download and >>> > test software on, which you can totally disconnect from your network >>> > (not JUST the internet), and which has NO confidential info, and which >>> > you can erase and rebuild without caring. Run the downloaded stuff >>> > there, for a long time, until you're pretty sure it won't bite you. >>> > >>> > 3 - For the REALLY REALLY paranoid, don't download anything from >>> > anywhere, disconnect from the internet permanently, get high-tech >>> > locks for your doors, and wrap your house in a faraday cage! >>> > >>> > And probably don't leave the house.... >>> > >>> > The point of number 3 is that there is always a risk, even with >>> > 'well-known' software, and as someone else said - they're watching you >>> > anyway. The question is how 'safe' do you want to be? And how >>> > paranoid are you, really? >>> > >>> > Wow, talk about rabbit hole! ;-) >>> > >>> > 'Let the flames begin!' :-) >>> > >>> > >>> > On 6/25/24 18:50, Ryan Petris via PLUG-discuss wrote: >>> >>> wanted sudo not to require a password. >>> >> Please reconsider this... This is VERY BAD security practice. There's >>> >> basically zero defense if you happen to download/run something >>> >> malicious. >>> >> >>> >> On Tue, Jun 25, 2024, at 6:01 PM, Michael via PLUG-discuss wrote: >>> >>> then I remember that a PLUG member mentioned ChatGPT being good at >>> >>> troubleshooting so I figured I'd give it a go. I sprint about half >>> >>> an hour asking it the wrong question but after that it took 2 >>> >>> minutes. I wanted sudo not to require a password. it is wonderful! >>> >>> now I don't have to bug you guys. so it looks like this is the end >>> >>> of the user group unless you want to talk about OT stuff. >>> >>> >>> >>> -- >>> >>> :-)~MIKE~(-: >>> >>> --------------------------------------------------- >>> >>> PLUG-discuss mailing list: [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
