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

Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

lists.busybox.net

Post reply on HN
Print view View original

101–110 of 131 posts

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#101

Post by gherkin0 »

eridius wrote: post #57
gherkin0 wrote: post #38

Earlier quoted context omitted.

> GPLv3 mandates that your hardware be insecure (because you cannot prevent a malicious actor from installing malicious software on someone's device, which would normally be done by requiring all updates to be codesigned by the manufacturer). I think that's wrong: http://www.gnu.org/licenses/gpl-faq.en.html#GiveUpKeys : > I use public key cryptography to sign my code to assure its authenticity. Is it true that GPLv3…

What you've just described is a completely insecure hardware platform. Giving out a second private key that can still be used to install third-party updates is just as insecure as giving out their normal private key, the only real difference is if anyone actually looks at the code signature they can tell the difference between third-party and first-party code. Allowing the user to lock out that second key doesn't fix…

> Allowing the user to lock out that second key doesn't fix anything because 99.99% of users will never do that, or even know it exists.

That's easily solved: On initial device setup, the user could be asked to explicitly disable the key by asking something like "Would you like to secure your device by permanently disallowing the installation of untrusted software? Y/N"

Also, as someone else clarified below, the alternate key I was proposing is unique to the device. So any attack against you would have to be tailored to your device. That leaves the main threats as: 1) an NSA-like shipment-interception and 2) someone getting access to your user key after the device is in your possession. 1) can be mitigated by buying your device in a random retail shop, and 2) can be prevented by immediately permanently clearing the user the key.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#102

Post by eridius »

dTal wrote: post #89
eridius wrote: post #57

Earlier quoted context omitted.

What you've just described is a completely insecure hardware platform. Giving out a second private key that can still be used to install third-party updates is just as insecure as giving out their normal private key, the only real difference is if anyone actually looks at the code signature they can tell the difference between third-party and first-party code. Allowing the user to lock out that second key doesn't fix…

>GPLv3 is fundamentally incompatible with having a secure hardware platform That's funny because Chromebooks ship with GPLv3 code.

I'm not familiar with the security model of Chromebooks. How does it work?

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#103

Post by gherkin0 »

eridius wrote: post #98
malka wrote: post #63

Earlier quoted context omitted.

Each user would get its own private key that could only be used on its own device. It could not be used to sign software for someone else device

Hmm, that's actually the first suggestion I've heard that's at least technically workable, though it's pretty darn impractical to do at any kind of scale.

> though it's pretty darn impractical to do at any kind of scale.

How so? It's a solved problem. Don't smartphones already have numerous device-specific identifiers and keys loaded to them? All they would really need to do is slap an extra sticker on the device with the device-specific key printed on it. For instance, my phone came with a sticker with its IMEI printed on it.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#104

Post by eridius »

dTal wrote: post #71
eridius wrote: post #30

Earlier quoted context omitted.

Or to put it another way, GPLv3 mandates that your hardware be insecure (because you cannot prevent a malicious actor from installing malicious software on someone's device, which would normally be done by requiring all updates to be codesigned by the manufacturer). And it's not just limited to software that would be installed on the hardware; companies like Apple won't even allow employees to install GPLv3 software…

Is there a problem with, say, printing the key on the device case, as is done with administrator passwords for consumer routers? Or, if you're worried about casual skimming, inside the case? Under a tamper seal if it makes you feel better? You're basically at the Chromebook security model by that point, which seems well-regarded around here. It's pointless anyway trying to "secure" hardware against a sufficiently det…

Physical access should not equal ownership. Haven't you been paying attention at all to the Apple vs FBI case? Apple works very hard to keep devices secure even when they're in the possession of someone else. Obviously in this particular case a third-party firm was able to crack the iPhone (though without saying how), but you can bet Apple is doing everything they can to figure out how and fix it.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#105

Post by Annatar »

majewsky wrote: post #83
Annatar wrote: post #48

The elephant in the room is /opt, /etc/opt, and /var/opt. The System V and filesystem hierarchy specifications say that those locations are, and I quote, "for third party and unbundled applications". Yet some distributions, like for instance Debian or Ubuntu, do not even include them, precluding commercial software vendors from ever delivering software for those operating systems (no, an unbundled application can nev…

> Yet some distributions, like for instance Debian or Ubuntu, do not even include them, precluding commercial software vendors from ever delivering software for those operating systems What? Why should it be impossible for a third-party package to just create /opt? They will probably need to extend the PATH and LD_LIBRARY_PATH, but /etc/profile.d is very much standardized AFAIK.

> Why should it be impossible for a third-party package to just create /opt?

It is not impossible, obviously, but /opt and such should come from the operating system's vendor, and the vendor should be the only one to decide which filesystem permissions to provide: 0755? root:bin or root:sys? root:root? bin:bin? The vendor should decide that, since a vendor is supposed to know their operating system best.

Third parties might not agree, or even decide correctly for that operating system.

This is system engineering and architecture, something which beside operating system vendors, software vendors do not have a clue about in the slightest.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#106

Post by Annatar »

dingaling wrote: post #94
majewsky wrote: post #83

Earlier quoted context omitted.

> Yet some distributions, like for instance Debian or Ubuntu, do not even include them, precluding commercial software vendors from ever delivering software for those operating systems What? Why should it be impossible for a third-party package to just create /opt? They will probably need to extend the PATH and LD_LIBRARY_PATH, but /etc/profile.d is very much standardized AFAIK.

Indeed Adobe Reader for Linux used to land itself in /opt on Ubuntu. The power of run-as-su installers...

The FHS thing in Debian and Ubuntu must be relatively new, I certainly have no recollection of it back then when we looked into delivering unbundled software for it. And we did look for it, and we even combed through the Debian packaging specification back then.

Whatever it might be, or has been, if Debian and Ubuntu did get /opt, /etc/opt, and /var/opt and are now one small step closer to being System V compliant (from which FHS stems), I for one am very glad for that.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#107

Post by paxcoder »

eridius wrote: post #16
paxcoder wrote: post #10

I want to react to the signature FUD: GPLv3 is clearly a superior copyleft license to GPLv2 despite Linus' latently permissive opinion on the anti-TiVoization clause.

It's not FUD, and GPLv3 is not clearly a superior license. It may surprise you to learn that different people value different things and have different opinions, and so want different licenses. GPLv3 is really a pretty extreme license that imposes a lot of restrictions that a lot of people simply don't want. If GPLv3 does what you want, by all means use it, but don't denigrate the choices other people make.

I explicitly said a superior copyleft license. That is, I stated the value I presuppose, and in this context GPLv3's superiority to GPLv3 is clear. What's "extreme" is denying users control of their own devices, not the reverse.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#108

Post by paxcoder »

eridius wrote: post #99
tremon wrote: post #88

Earlier quoted context omitted.

GPLv3 mandates that your hardware be insecure Oh please. It really doesn't, it merely mandates that the user is able to override a manufacturer's lockdown. Not that any nitwit should be able to override a user's lockdown.

A platform that is insecure-by-default and relies on users being knowledgeable and motivated enough to learn how to lock down their own devices is still an insecure platform.

People have taken their time to draw you a picture of a solution you could have come up with yourself. They are not talking about opt-in security, you are the only one. GPLv3 does not hinder security. You are furthering FUD.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#109

Post by Sanddancer »

SquareWheel wrote: post #9

How badly would things break if we tried to "fix" this split today?

Some OSes, like Solaris, have already "fixed" this. However, the uglier thing that needs fixed is the initrd/initramfs. It served a purpose in 2002, but now is almost totally a historical artifact that adds more complication to the boot process. On distros inflicted with it, it makes boot problems even harder to fix because you have a layer-0 filesystem that has its own set of basic tools that are not used, or visible, at any other time. It kinda made sense in 2002, when you had to make sure that your boot partition was in the first 8 gigs of the filesystem, but nowadays, it is just a source of redundancy and errors.

Re: Understanding the bin, sbin, usr/bin , usr/sbin split (2010)

#110

Post by dTal »

eridius wrote: post #102
dTal wrote: post #89

Earlier quoted context omitted.

>GPLv3 is fundamentally incompatible with having a secure hardware platform That's funny because Chromebooks ship with GPLv3 code.

I'm not familiar with the security model of Chromebooks. How does it work?

Out of the box, they only accept Google OS updates. For reference, the OS is basically Gentoo+Chrome.

If you've a mind to, you can put the Chromebook in "developer mode" with a magic sequence of commands (requiring physical access as it's a boot procedure). This gives you root. To protect naive users from being exploited, a Chromebook in developer mode will display a nasty warning on boot. This warning lingers on the screen for an annoying amount of time, accompanied by a beep. The only way (and it's undocumented) of skipping the wait and the beep is with Ctrl-D; pressing any other key while on this screen results in the Chromebook being completely reset. All this is to ensure that it's virtually impossible to run under developer mode unintentionally.

If all this gets too annoying and you want to use the Chromebook as a fully general device, you can blow it away by replacing the bootloader. Doing this requires disabling write-protection on the flash, which requires opening the case.

Disclaimer: I own a Samsung ARM Chromebook. For all I know the precise details may vary across the Chromebook line, though I believe they all work similarly. Fuller details are here: https://www.chromium.org/chromium-os/developer-information-f...

Post reply on HN