3 ms·
I think if it's a large org you should treat engineer machines as threat vectors by default, PoLP and all that jazz. Someone already posted here how they were
by moonchrome 3y ago
I think if it's a large org you should treat engineer machines as threat vectors by default, PoLP and all that jazz.
Someone already posted here how they were able to use PIP to hijack Google developer machines because on their machines defaults were to resolve to public repo first (even for private packages). Google just closed/ignored the issue because this was engineers problem and official build was setup to resolve correctly (this is my from memory summary)
- discreteevent 3y agoIf you apply principle of least privilege to developers then ideally you should have a whitelist of every software package that they need to use. What happens then when a productive developer, instead of developing from scratch, searches for a solution to some problem and discovers that there is already a module that may solve it? Do they go to some central committe to get approval to add it to the whitelist? What are their criteria? How long will it take them to approve it? Suppose it takes a couple of days. Then the developer tries the module. Discovers immediately that the module doesn't solve the problem. That's two days wasted for nothing. Suppose some module that has dependencies on a huge list of other modules. How long will it take now? I'm not saying polp isn't valid. But is it practical?
- moonchrome 3y ago> Do they go to some central committe to get approval to add it to the whitelist? What are their criteria? How long will it take them to approve it? Yes, depends on the org, depends on the org. Introducing third party dependencies should not be a single person decision.
- megous 3y agoOh, yeah. That's how I have to treat large orgs as a contractor. :) And trouble start almost immediately, because they apply PoLP only to you... First thing with a new client is usually some form of a VPN access. Even with open protocols, it's challenging to secure a VPN access. Eg. by default running openvpn with a random config provided by a third party allows the third party to push any network setup they want remotely. There's no whitelist, etc. It takes quite a bit of effort to run openvpn as unprivileged user and make it do all network setup via a trusted setuid helper tool that can do whitelisting of allowed network configurations. And oftentimes VPN has to be some closed source garbage. Management daemons for these require high privileges and take remote commands on how to reconfigure the network and god knows what else. They also can't deal with any non-basic networking setup. The first such VPN solution I had to briefly deal with (before telling the client that we'll want something secure for both sides and it's going to be a fixed wireguard config), was some Linux binary blob that I checked in ghidra before running, and one of the first things it did was scan the system for USB devices, and it had other hidden (to the end user, probably not to the buyer) remote management functionality absolutely irrelevant to a VPN software. Devs need to apply PoLP also to the clients. Otherwise it's quite easy to accidentally route networks of multiple different clients together via a dev's machine.
- moonchrome 3y agoI use a VM for each client. I host it on my desktop and then when I need to work from a laptop I just SSH into the VM. This way I never "forget to turn off the client VPN" and similar BS, and my client files don't get mixed up, etc.
- megous 3y agoThat works for a client or two. I'm already at ~20 and there will eventually be hundreds. Managing all that via random VMs and VPN solutions (I've had some require some smartphone app, and one time codes + pins just to connect to VPN) would just be sheer craziness if everyone was allowed their own VPN solution and network setup.