4 ms·

For the average linux user, key signing isn't really a big deal, imho. Running as a user and protecting root without running unnecessary services is your first

by qdog 14y ago

For the average linux user, key signing isn't really a big deal, imho. Running as a user and protecting root without running unnecessary services is your first step, after that it's all kind of iffy. Signing something from an untrusted source (Having dealt with having to revoke a bunch of Microsoft signed stuff not too long ago, I assure you Microsoft is not infallible) doesn't buy you a whole lot. If you build a driver yourself and sign it, ok. Actually that's probably the best way, download the nvidia driver, sign it with your own one-time key, and voila, even if someone pulls a Folgers Commercial on your driver, they really can't sign it, they don't even know where the one-time key came from. For a normal user, the effort to try and hack your own signing mechanism seems like it would be non-trivial. Figuring out how to hack a giant 'trusted' signer is a pot of gold at the end of the rainbow. I would not be suprised if there are more compromised signing authorities right now. Flame was signed with a msft key that was actually not meant to sign code, but for several years, since this key was from msft, people happily loaded and ran flame. I don't really think it's FUD to say trusting your security to the entity that attracts the most attention is not a great plan. Your points are good, except I disagree that Linux's only beef is parsing PE files, I think that's really the least of his concerns. Msft could deliver up its keys in any form, it won't solve the insecurity of not knowing if your signer has been breached. Good security is hard, I think that's the main problem with all of Linus's ideas.

crististm 14y ago
The average Linux user is technical by definition. They will care a big deal about this issue.
trotsky 14y ago
For the average linux user, key signing isn't really a big deal, imho. It isn't a big deal to the average user because os internals aren't a big deal to the average user. Never the less, linux hasplenty of industry standard security measures like IOMMU support, DEP, ASLR, containers, RBAC, seccomp and so on. You can't expect the average user to know what technical countermeasures they need anymore than you can expect them to know what garbage collection or interrupt coalescence strategy suits them best. It's important for folks with domain knowledge and pull requests to look out for them. The only problem in this case is the politicization rooted in hatred of a version of microsoft that differs considerably from the one that exists today. Running as a user and protecting root without running unnecessary services is your first step, after that it's all kind of iffy. That's advice from a different era. On the desktop (any flavor) the attack vectors are almost entirely malicious attachements, plugin exploits, browser and supporting library exploits, other random outbound clients and social engineering. While linux isn't a popular target, it is at least as vulnerable to these attacks as the others. And due to design issues in X windows, once you can run client native code it is trivial to sniff credentials from the next elevation event. While it's not infallibile, requiring the rootkit or bootkit to be signed by a CA raises the bar dramatically.
- qdog 14y ago
  I disagree that it's very political, I don't think it would be any better to designate the CA as Oracle, IBM or 37signals. If Red Hat wants to rely on msft as their CA, fine, but don't try and bring it to the kernel. I don't think running as an unprivileged user as often as possible is out of date. Yes, there are plenty of attack vectors, but there's no reason to make it easy. You could run your browser as a different user, so it can't ever see your sudo commands or whatever, just common sense. I'm not familiar with X window exploits to sniff credentials, but I would assume the application being run as a different user than the x session would add difficulty? FYI my day job is dealing with Windows, driver signing/loading issues, and what have you. I have very low expectations for the security-mindedness of average users. Many people will click on a link after an AV "warning", because "Hey, the AV will stop it if it's really an issue!"

by qdog 14y ago

crististm 14y ago

The average Linux user is technical by definition. They will care a big deal about this issue.

trotsky 14y ago

For the average linux user, key signing isn't really a big deal, imho. It isn't a big deal to the average user because os internals aren't a big deal to the average user. Never the less, linux hasplenty of industry standard security measures like IOMMU support, DEP, ASLR, containers, RBAC, seccomp and so on. You can't expect the average user to know what technical countermeasures they need anymore than you can expect them to know what garbage collection or interrupt coalescence strategy suits them best. It's important for folks with domain knowledge and pull requests to look out for them. The only problem in this case is the politicization rooted in hatred of a version of microsoft that differs considerably from the one that exists today. Running as a user and protecting root without running unnecessary services is your first step, after that it's all kind of iffy. That's advice from a different era. On the desktop (any flavor) the attack vectors are almost entirely malicious attachements, plugin exploits, browser and supporting library exploits, other random outbound clients and social engineering. While linux isn't a popular target, it is at least as vulnerable to these attacks as the others. And due to design issues in X windows, once you can run client native code it is trivial to sniff credentials from the next elevation event. While it's not infallibile, requiring the rootkit or bootkit to be signed by a CA raises the bar dramatically.

qdog 14y ago
I disagree that it's very political, I don't think it would be any better to designate the CA as Oracle, IBM or 37signals. If Red Hat wants to rely on msft as their CA, fine, but don't try and bring it to the kernel. I don't think running as an unprivileged user as often as possible is out of date. Yes, there are plenty of attack vectors, but there's no reason to make it easy. You could run your browser as a different user, so it can't ever see your sudo commands or whatever, just common sense. I'm not familiar with X window exploits to sniff credentials, but I would assume the application being run as a different user than the x session would add difficulty? FYI my day job is dealing with Windows, driver signing/loading issues, and what have you. I have very low expectations for the security-mindedness of average users. Many people will click on a link after an AV "warning", because "Hey, the AV will stop it if it's really an issue!"