Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

/bin/sh: the biggest Unix security loophole (1984) [pdf]

tuhs.org

Post reply on HN
Print view View original

41–50 of 57 posts

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#41

Post by fargle »

lostlogin wrote: post #24
netsharc wrote: post #4

Earlier quoted context omitted.

In the Middle Ages, when Internet access wasn't in your pocket all the time, I was in a hostel which had Internet kiosks, you'd put a coin in a machine, and the PC would start 2 browser windows: 1 with just a countdown, and one for you to browse. You'd have to put more coins or when the time ends the browser would be killed. Of course there was nothing else in the UI except this window and the browser, but on ancient…

This is excellent, and while I’m guessing that you could have paid, browsed and moved on with less effort, that wasn’t the point.

that's pretty low effort, so not really. but cool. win-win.

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#42

Post by fargle »

mingus88 wrote: post #14
supriyo-biswas wrote: post #3

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.

As someone who used to sysadmin and was well aware of this trick, sometimes a developer or dba will bully their way through leadership to make sure they never need to ask for permission to edit their configs 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…

they only needed a backdoor root because you're a gatekeeping dick and they wanted to get their job done without having to "deal" with your shit.

OMG. they applied unapproved patches! to the product they were responsible for making work.

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#43

Post by fargle »

athrowaway3z wrote: post #26

>Ritchie is the inventor of the elegant setuid concept, for which a patent was awarded. Do organization still apply for these kind of patents?

yes. most very large corps. that like to keep patent portfolios will encourage engineers to patent (assigned to the co. of course) anything slightly creative or unusual. or sometimes anything at all that sounds slightly technical.

the engineer gets his name on the patent and maybe a bit of prestige. the org gets another (sometimes bad) patent in the portfolio.

skimming the patent https://patents.google.com/patent/US4135240A/en it seems actually pretty well drafted and pretty good (patentable).

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#44

Post by mingus88 »

fargle wrote: post #42
mingus88 wrote: post #14

Earlier quoted context omitted.

As someone who used to sysadmin and was well aware of this trick, sometimes a developer or dba will bully their way through leadership to make sure they never need to ask for permission to edit their configs 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…

they only needed a backdoor root because you're a gatekeeping dick and they wanted to get their job done without having to "deal" with your shit. OMG. they applied unapproved patches! to the product they were responsible for making work.

lol, restricting administrative access to the administrators is pretty much a security best practice in every company everywhere.

Ever heard of the principle of least privilege?

They didn’t give me admin in the database and I don’t want it. They aren’t trained in the system and if you’ve ever seen what kind of mess a bunch of amateurs can make of a shared system you wouldn’t sound like such an idiot right now

Ill be sure to tell the auditors that they are gatekeeping dicks for requiring change management on the financial databases

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#45

Post by josephcsible »

mingus88 wrote: post #14
supriyo-biswas wrote: post #3

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.

As someone who used to sysadmin and was well aware of this trick, sometimes a developer or dba will bully their way through leadership to make sure they never need to ask for permission to edit their configs 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…

Nobody should ever need permission to edit their own configs. E.g., if a box is used solely as a database server, then the DBAs should have full root to it.

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#46

Post by fargle »

mingus88 wrote: post #44
fargle wrote: post #42

Earlier quoted context omitted.

they only needed a backdoor root because you're a gatekeeping dick and they wanted to get their job done without having to "deal" with your shit. OMG. they applied unapproved patches! to the product they were responsible for making work.

lol, restricting administrative access to the administrators is pretty much a security best practice in every company everywhere. Ever heard of the principle of least privilege? They didn’t give me admin in the database and I don’t want it. They aren’t trained in the system and if you’ve ever seen what kind of mess a bunch of amateurs can make of a shared system you wouldn’t sound like such an idiot right now Ill be…

that is all true. but admins need to be aware of the reasons other groups desire to go around them. obviously they needed some patches on their database product.

OK, what's the easiest way to get it? option 1: call the IT admin and say "hey bud, can we get these patches and see if it fixes my thing?" or option #2 play some political long game to get sudo vi access via intense political pressure and then hack into the system to install said patches.

if you have to do option #2, then it's the FAULT of the IT system: people follow the path of least resistance. if there was so much hassle having a support organization actually help you such that it was actually easier to do it yourself and fighting (and winning) some political fight with the other dept. to get there, you tell me what's wrong with that support org?

this is why DevOps is an improvement.

you're trying to point at the auditors as being the dicks? nope. any engineer in the company can be equally responsible for configuration management. wanna bet that the IT dept. has no process to allow other engineers to update configuration? or that they won't do it on your behalf in a timely fashion? simply delegate the patch configuration management of the DB to the DBAs and send the auditors to see the experts. there's a good chance they'd take the responsibility seriously and do a better job of it than you.

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#47

Post by Dwedit »

fph wrote: post #17
dehrmann wrote: post #16

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.

Shared Web Hosting still uses multiple users.

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#48

Post by [deleted] »

calvinmorrison wrote: post #37
adrian_b wrote: post #20

Earlier quoted context omitted.

While most computers are personal computers, which have a single real human user, you still have to run a lot of untrusted programs, like the Internet browsers or whatever programs you might download from dubious sources. 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…

So, basically all my sandbox concerns go away if I run as root and every browser runs as its own user

[deleted]

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#49

Post by Too »

adrian_b wrote: post #20
fph wrote: post #17

Earlier quoted context omitted.

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 most computers are personal computers, which have a single real human user, you still have to run a lot of untrusted programs, like the Internet browsers or whatever programs you might download from dubious sources. 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…

Android works like this. It's linux based and runs every app as its own user. On top of that it adds SELinux and many other isolation strategies.

https://source.android.com/docs/security/app-sandbox

Re: /bin/sh: the biggest Unix security loophole (1984) [pdf]

#50

Post by IshKebab »

Vogtinator wrote: post #23
dehrmann wrote: post #16

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.

For multiple users on the same server it was IMO well designed. Everyone had their ~ and could place whatever libraries/binaries/etc. in there and do whatever they wanted. Package managers are way more modern than that and their design does by itself not require root (see pip). You can in fact run most package managers without root, you just won't be able to modify system files. You can use them to install a chroot a…

Oh yeah? How can I install Clang using Apt without root?
Post reply on HN