6 ms·

Which is slightly scary security wise. Over the large number of libs, programs, etc people often pull half-blind if the code looks "mostly ok and does what it s

by zobzu 14y ago

Which is slightly scary security wise. Over the large number of libs, programs, etc people often pull half-blind if the code looks "mostly ok and does what it says" Except it can do also a lot of other bad things, and its too much to review. So in the end you trust the tree owner, and he blindly trust a zillion people. I actually have zero good solution to this, but it'll be interesting when it is used for a large attack.

rhizome 14y ago
As far as the headline goes, not running any of this as root is a good start.
- benatkin 14y ago
  That by itself is rarely a solution, especially these days. People store very important stuff in their home directories. It would need to be something like an isolated user account, a virtual machine, or a browser window.
- deleted 14y ago
  [deleted]
adgar2 14y ago
> Except it can do also a lot of other bad things, and its too much to review. So in the end you trust the tree owner, and he blindly trust a zillion people. > I actually have zero good solution to this, but it'll be interesting when it is used for a large attack. The only solution is intelligence and prudence on the part of the tree owners. Large software systems need to ultimately be in the hands of smart and wise people. Unfortunately, that wasn't the case here.
- benatkin 14y ago
  > Large software systems need to ultimately be in the hands of smart and wise people. Unfortunately, that wasn't the case here. Wow, it must be awesome to be you.
  - adgar2 14y ago
    Didn't say I was one of them. Enjoy your strawman. Personally, I prefer a bit more flavor. Though your implicit ad-hominem tastes a bit juicy. Writing a package manager is actually really serious business. This package manager runs under user credentials and is expected to modify the filesystem. You can't sandbox around those requirements. No amount of whinging avoids that. This story is one of many examples why you can't take it trivially. If you're afraid to point out incompetence - and where it is most dangerous - you won't know it when you see it. And it will bite you, hard.
    - grannyg00se 14y ago
      I upvoted your response because on one hand I do think you are correct in all of what you are saying. But your previous post can be interpreted as an implication that the people themselves are neither smart, nor wise. A somewhat harsh attack. I re-read it with more emphasis on the "here" part of the sentence and it sounded a bit more as though you are saying that in this instance the people were not wise. Pointing out incompetence is helpful, but it's also very useful to do so in a way that attempts to minimize the chance of an extremely negative interpretation.
      - adgar2 14y ago
        I expected an extremely negative interpretation. My criticism is harsh because the failure here was unacceptable. Look at the pull request they merged in. Any line added to a script which starts with "rm -rf $VARIABLE" cannot be scrutinized enough. The first commit was created at: 2012-09-30T10:25:44-07:00. The pull request was accepted at: 2012-09-30T10:59:08-07:00. 34 minutes to accept on a Sunday morning. I suspect that wasn't 34 minutes of review. I suspect it was closer to 34 seconds of review. Unacceptable.
        tjholowaychuk 14y ago
        shit happens, and then you die. when you have 50+ people that just "+1" an issue for long enough without helping, you tend to limbo-merge
- deleted 14y ago
  [deleted]
- thirsteh 14y ago
  http://cm.bell-labs.com/who/ken/trust.html http://cm.bell-labs.com/who/ken/trust.html
  - adgar2 14y ago
    Do you actually think Ken disagrees with me? Hint: he doesn't. He wouldn't accept a line of code starting with "rm -rf $VAR" in ~30 minutes on a Sunday morning.
    - thirsteh 14y ago
      Try not to take offense from things so easily. I linked Ken's paper because it's related. His conclusion is that it doesn't matter how smart the users or maintainers are if somebody wants to install a clever bug. Smart and clever people can still choose not to accept contributions from people they don't know.
      - zobzu 14y ago
        basically they have to earn trust before they can do this i actually have some half solutions, that many use. one of these is code signing (digital signing or simple "signed off by" from an email that you believe belongs to the owner, even thus the first is stronger) this means, the person may eventually do bad stuff, after earning your trust. OK. But if that's ever detected, at least you can trace back to him.
benatkin 14y ago
Ultimately the tree owners need to be bigger and have more resources devoted to them. The rails project routinely gets major bugs fixed in under a day.
biturd 14y ago
> I actually have zero good solution to this, but it'll > be interesting when it is used for a large attack. I don't know what this software is or anything about it aside from an estimating that it appears from comments here and on GH that it's serious as it deletes highly important directories and is possibly a widely used software package. Whenever I install from source I run the installer as non root. It will error on higher than my user privilege deletes telling me I need to be root. In this case I believe I would have seen the attempt to remove important directories as an error alert. If I have to be root, running as non root first has helped me as a purely investigative method to installations. What if everyone adopted an 'rm -rfi' type command for any deletes. Then you are asked: "You are about to remove $dir are you sure you are okay with this? Y/N? In this case, what I don't get is how it's now been three days and there hasn't been a rollback, pulling of the software, patch, notice, billboard, radio announcement, Emergency Broadcast Syatem alert, or otherwise some way to halt this problem dead in it's tracks right this very second. It's almost like: README This software is 'use at your own risk', etc., etc., etc., see Hacker News for any potentially dangerous side-effects caused by installing this software.
- mikebannister 14y ago
  everything in my /usr/local is owned by my user. isn't this typical in the case of a dev machine?
  - wtallis 14y ago
    If it's going to be owned by your non-root account, shouldn't it be installed to ~/? It seems like a bad idea for a non-root user to have control over binaries that are in root's $PATH.
    - dagw 14y ago
      On a server or an environment where you don't trust your users, absolutely. On your own private dev machine that's only used by you, doing things the 'wrong' way is often perfectly acceptable and makes life easier.
    - 14y ago

by zobzu 14y ago

rhizome 14y ago

As far as the headline goes, not running any of this as root is a good start.

benatkin 14y ago
That by itself is rarely a solution, especially these days. People store very important stuff in their home directories. It would need to be something like an isolated user account, a virtual machine, or a browser window.
deleted 14y ago
[deleted]

adgar2 14y ago

> Except it can do also a lot of other bad things, and its too much to review. So in the end you trust the tree owner, and he blindly trust a zillion people. > I actually have zero good solution to this, but it'll be interesting when it is used for a large attack. The only solution is intelligence and prudence on the part of the tree owners. Large software systems need to ultimately be in the hands of smart and wise people. Unfortunately, that wasn't the case here.

benatkin 14y ago
> Large software systems need to ultimately be in the hands of smart and wise people. Unfortunately, that wasn't the case here. Wow, it must be awesome to be you.
- adgar2 14y ago
  Didn't say I was one of them. Enjoy your strawman. Personally, I prefer a bit more flavor. Though your implicit ad-hominem tastes a bit juicy. Writing a package manager is actually really serious business. This package manager runs under user credentials and is expected to modify the filesystem. You can't sandbox around those requirements. No amount of whinging avoids that. This story is one of many examples why you can't take it trivially. If you're afraid to point out incompetence - and where it is most dangerous - you won't know it when you see it. And it will bite you, hard.
  - grannyg00se 14y ago
    I upvoted your response because on one hand I do think you are correct in all of what you are saying. But your previous post can be interpreted as an implication that the people themselves are neither smart, nor wise. A somewhat harsh attack. I re-read it with more emphasis on the "here" part of the sentence and it sounded a bit more as though you are saying that in this instance the people were not wise. Pointing out incompetence is helpful, but it's also very useful to do so in a way that attempts to minimize the chance of an extremely negative interpretation.
    - adgar2 14y ago
      I expected an extremely negative interpretation. My criticism is harsh because the failure here was unacceptable. Look at the pull request they merged in. Any line added to a script which starts with "rm -rf $VARIABLE" cannot be scrutinized enough. The first commit was created at: 2012-09-30T10:25:44-07:00. The pull request was accepted at: 2012-09-30T10:59:08-07:00. 34 minutes to accept on a Sunday morning. I suspect that wasn't 34 minutes of review. I suspect it was closer to 34 seconds of review. Unacceptable.
      - tjholowaychuk 14y ago
        shit happens, and then you die. when you have 50+ people that just "+1" an issue for long enough without helping, you tend to limbo-merge
deleted 14y ago
[deleted]
thirsteh 14y ago
http://cm.bell-labs.com/who/ken/trust.html http://cm.bell-labs.com/who/ken/trust.html
- adgar2 14y ago
  Do you actually think Ken disagrees with me? Hint: he doesn't. He wouldn't accept a line of code starting with "rm -rf $VAR" in ~30 minutes on a Sunday morning.
  - thirsteh 14y ago
    Try not to take offense from things so easily. I linked Ken's paper because it's related. His conclusion is that it doesn't matter how smart the users or maintainers are if somebody wants to install a clever bug. Smart and clever people can still choose not to accept contributions from people they don't know.
    - zobzu 14y ago
      basically they have to earn trust before they can do this i actually have some half solutions, that many use. one of these is code signing (digital signing or simple "signed off by" from an email that you believe belongs to the owner, even thus the first is stronger) this means, the person may eventually do bad stuff, after earning your trust. OK. But if that's ever detected, at least you can trace back to him.

benatkin 14y ago

Ultimately the tree owners need to be bigger and have more resources devoted to them. The rails project routinely gets major bugs fixed in under a day.

biturd 14y ago

> I actually have zero good solution to this, but it'll > be interesting when it is used for a large attack. I don't know what this software is or anything about it aside from an estimating that it appears from comments here and on GH that it's serious as it deletes highly important directories and is possibly a widely used software package. Whenever I install from source I run the installer as non root. It will error on higher than my user privilege deletes telling me I need to be root. In this case I believe I would have seen the attempt to remove important directories as an error alert. If I have to be root, running as non root first has helped me as a purely investigative method to installations. What if everyone adopted an 'rm -rfi' type command for any deletes. Then you are asked: "You are about to remove $dir are you sure you are okay with this? Y/N? In this case, what I don't get is how it's now been three days and there hasn't been a rollback, pulling of the software, patch, notice, billboard, radio announcement, Emergency Broadcast Syatem alert, or otherwise some way to halt this problem dead in it's tracks right this very second. It's almost like: README This software is 'use at your own risk', etc., etc., etc., see Hacker News for any potentially dangerous side-effects caused by installing this software.

mikebannister 14y ago
everything in my /usr/local is owned by my user. isn't this typical in the case of a dev machine?
- wtallis 14y ago
  If it's going to be owned by your non-root account, shouldn't it be installed to ~/? It seems like a bad idea for a non-root user to have control over binaries that are in root's $PATH.
  - dagw 14y ago
    On a server or an environment where you don't trust your users, absolutely. On your own private dev machine that's only used by you, doing things the 'wrong' way is often perfectly acceptable and makes life easier.
  - 14y ago