13 ms·

Honest question: Why does anyone still care about root escalation on workstations? When do we stop pretending our MacBooks are multi-user UNIX mainframes? App

• vezzy-fnord 11y ago
  When do we stop pretending our MacBooks are multi-user UNIX mainframes? This is actually a good point, even if I disagree with your minimization of privsep's importance.
• vortico 11y ago
  This is my view as well---not sure why it was downvoted. If I have access to ~/.mozilla and ~/.chrome in userspace, I probably have access to your email password.
• MrTonyD 11y ago
  I was part of the original UNIX porting team at NeXT, and we were just trying to get the most popular non-proprietary operating system (UNIX) modernized (by using Avie's CMU Mach) as the modern core to a standard OS. We didn't even think about any server type applications. And Steve told us that he was tired of being beaten-up at Apple for being closed source - so he wanted UNIX. (As an aside, he refused to allow any object-oriented tools in the system - but in Engineering we realized that Steve wouldn't know an object-oriented system from a hole in the ground, so we ignored his direct orders to not put in anything object oriented. The rest is history.)
  • feelix 11y ago
    Why was he against object orientation?
    • stcredzero 11y ago
      My guess: Back at that time, it was harder to afford the extra resources for OO. It's not until the time I graduated college that machines and VMs of managed environments started to get faster than "embarrassingly slow" in mainstream hands. This is also a big part of the reason why there were languages like Eiffel and also why C++ got so entrenched. Also explains the existence of Objective-C.
      • reagency 11y ago
        And indeed, even when Macs had faster hardware (early PowerPC), the Objective-C crippled performance. Windows crashed a lot (like Mac did before OS X), but it was fast because it had no isolation between components.
        • empthought 11y ago
          There was no Objective-C in Apple software in the days of "when Macs had faster hardware (early PowerPC)." The state-of-the art at OS X's release was the fourth-generation PowerPC, and there was only one more major iteration of the PowerPC used in Macs. I would call this "later PowerPC." "Early PowerPC" Macs couldn't run OS X.
          • pjmlp 11y ago
            But there was Object Pascal and C++.
      • cbd1984 11y ago
        > the extra resources for OO Thinking like this annoys me, because it assumes a specific implementation for OO. Are people conflating OO with Java? Are they conflating it with Smalltalk? Are they unaware you can write C in an OO style? > It's not until the time I graduated college that machines and VMs of managed environments started to get faster than "embarrassingly slow" in mainstream hands. Yes. People are apparently conflating OO with Java or Smalltalk.
        • cynicalkane 11y ago
    • secstate 11y ago
      Just a guess here, but true object-orientation is really hard to get right. It's not like OS X was going to be built on Smalltalk. And if you're going to half-ass OO with an implementation like structs+functions, you're usually better off sticking with a functional system. This is especially true when it comes to high availability services, like operating systems.
      • cbd1984 11y ago
        http://c2.com/cgi/wiki?DefinitionsForOo http://c2.com/cgi/wiki?DefinitionsForOo Given the above link, I deny there's any single useful definition for OO: It's been defined and redefined over and over again for decades, to the point people can't even agree on what languages are capable of writing software in an OO style.
    • tacone 11y ago
      Probably because of the hype. He was promoting OO and thinking about it as a competitive advantage over the competition. He probably didn't want such "powerful" (?) software to be reused by them.
    • MrTonyD 11y ago
      Steve didn't understand OO at the time. Not in the least. Steve was completely non-technical, and he knew that UNIX was standard and didn't want us putting something new and untested in it. I can't tell you how many times I tried to explain OO concepts to him (lots of us tried, over and over.) So, to him, an OO toolkit was something that would make us too complex for developers looking for an easily understood UNIX system. He told us that he was relying on people's existing understanding of UNIX - that would allow them to adopt our system.
      • feelix 11y ago
        There are always casualties when managers make decisions and policies based on things they have absolutely no understanding of. At least programmers were able to do it anyway with this particular case, as Steve had no way of knowing it was happening.
  • pazimzadeh 11y ago
    Really interesting. What do you make of video like these? https://www.youtube.com/watch?v=2kjtQnPqq2U https://www.youtube.com/watch?v=2kjtQnPqq2U https://youtu.be/SaJp66ArJVI?t=2m04s https://youtu.be/SaJp66ArJVI?t=2m04s
    • MrTonyD 11y ago
      I remember those days, and I remember Steve saying many of those things. Steve didn't have any deep understanding of what he was saying, and he spent a lot of time working on the wording of those sentences - practicing them over and over with a few of us in Engineering and Product Management. He created those sentences based on what engineers were telling him - reformulating them into his personal style. Really, Steve would often say that he couldn't do what we were doing, but he could help sell it. He described himself as a marketing guy - and that is what he was.
      • yuhong 11y ago
        I wonder how he compared with John Sculley at this time.
  • reagency 11y ago
    That is classic Jobs -- sort of techie but not understanding what any of the words mean, very demanding, and sensitive to the customers' biases.
    • crusso 11y ago
      Thus proving that all our nerdy knowledge isn't as important as we think it is in order to be incredibly successful.
      • mwfunk 11y ago
        Very true. Our biases sometimes even get in the way of creating things that people want.
    • simonh 11y ago
      At the time, and for a long time after, a lot of computer science types were arguing that everything should be implemented from the ground up in very high level OO languages and abstracted runtime environments and this was the inevitable way things would be. Just look at the discussion on HN right now about smalltalk. Java also came out of this mindset. But Steve came form a highly practical, nuts-and-bolts engineering mindset where perfect is the enemy of the good. So I think Steve's attitude has to be put into the context of that conflict. But as MrTonyD shows, there were people at NEXT who understood how to translate that attitude into practical terms. And to be fair to Steve that's because he knew how to hire absolutely tip-top talent and trust them to do their jobs right, even when they disagreed with him.
      • wtbob 11y ago
        > At the time, and for a long time after, a lot of computer science types were arguing that everything should be implemented from the ground up in very high level OO languages and abstracted runtime environments and this was the inevitable way things would be. I don't really see that they were wrong. After all, C and POSIX are also very high level and abstracted compared to the assembler-based OSes which existed before them. The big problem now is that to be a successful alternate OS one needs to be bug-for-bug compatible with POSIX, and have a C compiler, in addition to one's own language and OS. Perhaps recent years' developments in virtualisation and containerisation will make it easier for a non-Linux host to run a Linux kernel and hand containers to it as needed. Maybe one day OS and systems research will once again pay off.
  • yuhong 11y ago
    I have been wondering what would happen if Apple did the Blue Box on NuKernel path instead of the Rhapsody/Mac OS X path for a while now.
• soneil 11y ago
  I've always wondered this. root on my laptop gives them .. all the things I can reinstall from a vendor image. My user, however, gives them my email, my photos, my tax returns, etc. Separation still sounds like a good theory, but I do wonder if we're putting a lot of effort into defending the wrong user.
  • justinsaccount 11y ago
    Exactly.. sandboxing helps with this, not unix style permissions. You still see a ton of comments saying things like "OS X and linux are secure because they use unprivileged accounts". But the security on unix is primarily to secure user alice from something that user bob does. It doesn't secure user alice from something that alice does. If alice gets infected with a cryptolocker trojan, it can't touch bobs files, but it can encrypt all of hers. On a single user system that only has an alice account, what is needed is to secure 'tax program' from something that 'web browser' does.
  • PhantomGremlin 11y ago
    It's simple to create multiple users on OS X. It's quick to switch between them. E.g. I have a separate user that I switch to just to contact a handful of credit card / bank sites. Same with tax returns. I don't do them as my normal user. They are not readable from my main account. But I don't do enough. E.g. email and photos are still accessible. Fortunately I lead an uninteresting life. The main threat to/from my photos is accidental deletion, filesystem corruption, drive crashes, etc. TMZ isn't going to pay anyone to steal them! The problems are not simple to solve. What I've done is simple half-measures. It's very hard to do more than that. Edit: and, of course, my normal user is "Standard", not "Admin". I switch to the admin user whenever I do sys admin. I never elevate privileges from my normal account.
    • coldtea 11y ago
      >It's simple to create multiple users on OS X. It's quick to switch between them. It's also something 95% of OS X users don't do or care about.
    • 11y ago
• viraptor 11y ago
  I don't know if all of this applies to OSX, but I'll answer from Linux perspective. (some of these are in common, I'm sure) There are restrictions for your user that you can set up as root, but your user can't touch. For example firewall, process restrictions, security labels, etc. What does it mean in practice: if you set up appropriate restrictions and run (for example) `curl http://...` http://...` and curl gets exploited via malformed response: - it cannot write to system configuration - it cannot write to user configuration - it cannot spawn shell - it cannot bind port to get remote commands - even if it could, it cannot receive traffic, because it's configured as outbound-only - while it can send data on the same connection, there's not much to send, because: - it cannot read your browser saved items (password, history, etc.) - it cannot read your ssh configuration / keys ... So yes, superuser access is still important, because it can set up defences which only superuser can override. Not many systems use it so far, but the frameworks are available. I think the biggest impact currently in this area is the Chrome sandbox, but this one can be actually user-activated.
  • rodgerd 11y ago
    If an attacker successfully compromises my workstation and can masquerade as me, and the most useful thing they can think of doing is to pivot and rewrite my SELinux rules as opposed to, grab my password database (or just keylog my banking sessions), then I will be a very happy man. I think mobile actually leads the way in this area, with applications restricted in actions they can take, regardless of who they're running.
    • viraptor 11y ago
      My point was - before they can read the password database (or even find that a password database exists), they need to break out of selinux enforced rules. It's not an end goal - it should be a prerequisite for any further data collection. Key logging should not be possible in an exploited application either. Actually if you've got some healthy paranoia, you're maybe running QubesOS and your banking doesn't touch any other work environments. Of course this is tricky in case of browsers. But that's also why I don't keep my password in the browser ;)
• jfb 11y ago
  Take it a step further: why is there even still a root user? Separation of privileges doesn't require the user abstraction.
• jghn 11y ago
  For the same reason we did 25 years ago. If I somehow get network access to your machine I'll blow out a stack and have root. Yes it seems difficult but it's easy to get wifi passwords and people use the same passwords and ....
• vacri 11y ago
  > When do we stop pretending our MacBooks are multi-user UNIX mainframes? My computers at home have multiple users, because they have their individual preferences setting their desktops and browsers the way they like My computers at work, laptops and otherwise, have other devs' accounts on them, so they can ssh in and grab stuff, or play with setups I have on my machine. It's a particularly easy way for me to distribute VPN keys... and of course, users can't read each other's private files. If I'm away and someone needs a computer to work, they can use my machine without each of us messing with each other's setup. Multiple-meatspace-user machines certainly aren't as popular these days, but they're not as dead-and-buried as you're implying. Just because mainframes are no longer the big cheese doesn't mean that there's no call for multiuser machines.
• rdl 11y ago
  I hope we can fix this with sandboxing (maybe with containers, but maybe just per-process). This is going to be the most exciting thing about SGX, which is allegedly coming out in a month, after many many years of anticipation.
• sz4kerto 11y ago
  I think this is completely wrong -- look at UAC on Windows, that works very well. Even if the machine is completely single-user, you don't want any program you run to be able to modify system files, etc. It is useful to manually grant elevated access if a program needs it, as then any downloaded code could install spyware, etc. On Windows (and on Linux), bypassing these mechanisms is certainly possible, but not trivial. And that is good for the user.
• yAnonymous 11y ago
  > if x happens, we should stop caring about y That kind of argumentation usually ends badly, especially when it's about security.