11–20 of 57 posts
Loopholes of this kind exist these days as well. When I was working for a major retailer, who, you'd assume would have thought about these things well enough, you were prevented from executing sudo, except for being able to use it for text editing (sudo vi). I needed to install some packages with a root shell at the time, so I used the command execution feature within vi to get that.
Wow, they even used the accurate term "crackers", I feel so old.
1984 was 40 years ago.
They confed /etc/sudoers so that the perforce user can run everything as root without providing a password. I told them that this is really a bad idea, and they pulled up one of their setup guides with "enhanced security hardening".
It ended up with ~35 specific entries for binaries in sudoers, one of them being /usr/sbin/setcap - which allows you to give e.g. the Python interpreter CAP_SETUID, making a privilege escalation to root trivial again.
Loopholes of this kind exist these days as well. When I was working for a major retailer, who, you'd assume would have thought about these things well enough, you were prevented from executing sudo, except for being able to use it for text editing (sudo vi). I needed to install some packages with a root shell at the time, so I used the command execution feature within vi to get that.
We all knew it was a bad idea but when your boss and their boss say do it, it’s done.
I’m pretty sure the dba (autocorrect magically suggested “diva” here) knew as well and just wanted a backdoor to have root for whatever they wanted.
I later busted the same team applying patches out of band with tripwire. Hey, wonder how you pulled that off…
I fear that this reference to an old Avis advertising slogan may be lost to a modern audience.
I had the "joy" of watching some guys from Perforce setup a new p4 instance. They confed /etc/sudoers so that the perforce user can run everything as root without providing a password. I told them that this is really a bad idea, and they pulled up one of their setup guides with "enhanced security hardening". It ended up with ~35 specific entries for binaries in sudoers, one of them being /usr/sbin/setcap - which allo…
I had the "joy" of watching some guys from Perforce setup a new p4 instance. They confed /etc/sudoers so that the perforce user can run everything as root without providing a password. I told them that this is really a bad idea, and they pulled up one of their setup guides with "enhanced security hardening". It ended up with ~35 specific entries for binaries in sudoers, one of them being /usr/sbin/setcap - which allo…
We love to praise Unix, but it wasn't built for modern multi-user use. FUSE was an after-thought. So were package managers, and they got added, but they require root. Users aren't sandboxed, so they can see what others are doing. These were just off the top of my head.
I had the "joy" of watching some guys from Perforce setup a new p4 instance. They confed /etc/sudoers so that the perforce user can run everything as root without providing a password. I told them that this is really a bad idea, and they pulled up one of their setup guides with "enhanced security hardening". It ended up with ~35 specific entries for binaries in sudoers, one of them being /usr/sbin/setcap - which allo…
We love to praise Unix, but it wasn't built for modern multi-user use. FUSE was an after-thought. So were package managers, and they got added, but they require root. Users aren't sandboxed, so they can see what others are doing. These were just off the top of my head.
The authors of Unix have taken most of the concepts of an hierarchical file system from Multics, the main exception being the security features, which have been replaced with the simpler owner-group-all permission bits, together with features like setuid/setgid, which may be OK for simple use cases but which is inadequate for a system with many users, where not all of them can be trusted.
I had the "joy" of watching some guys from Perforce setup a new p4 instance. They confed /etc/sudoers so that the perforce user can run everything as root without providing a password. I told them that this is really a bad idea, and they pulled up one of their setup guides with "enhanced security hardening". It ended up with ~35 specific entries for binaries in sudoers, one of them being /usr/sbin/setcap - which allo…
We love to praise Unix, but it wasn't built for modern multi-user use. FUSE was an after-thought. So were package managers, and they got added, but they require root. Users aren't sandboxed, so they can see what others are doing. These were just off the top of my head.
Earlier quoted context omitted.
We love to praise Unix, but it wasn't built for modern multi-user use. FUSE was an after-thought. So were package managers, and they got added, but they require root. Users aren't sandboxed, so they can see what others are doing. These were just off the top of my head.
Is multi-user use "modern"? Back in the days everyone shared the same mainframe, now I'd say most computer systems have a single user.
While perhaps the term "user" is no longer the best, there is a need even more than before to run programs with limited rights, corresponding to the rights of some pseudo-users, which should not be able to access or modify anything belonging to the real human user, unless a special permission is granted.