Comment by ksk | Hacker News Reader

Comment by ksk | Hacker News Reader

Parent Full thread

Thanks for taking the time to reply.

--

I don't understand how only allowing signed execution would help avoid this problem. Like you said, anyone could pay to get their company listed as a 'trusted' entity. The problem is you cant push this task to the user, because the non-technical layman user is not in a position to determine this.

If we only allow signed binaries to be loaded in memory, then we won't need IPC to pay the security tax for every function call. - given that there are probably going to be tens of thousands of them per second.

>We should get away from distributing compiled code that runs straight on bare metal for most things. [..] Honestly I'm not sure if it's necessary.

Poof, no more program debuggers, profilers, no more device drivers, no more third party file systems, no more .. you get the idea. Maybe that's not "most" things, but ask yourself how functional is an OS without the ability to load kernel mode stuff.

> Each user should have a key and be able to authorize other keys by signing them, etc.

How does that help my mom? She's just going to call me when the computer asks her "weird questions about keys and permissions". The entire point is that the average user is not the best judge of what is and isn't malware. Technically savvy users already have no issue with malware for the most part.

>Develop something good enough and the user can be put in the driver's seat without it turning into a malware safari.

Again, why would the user WANT to be in the drivers seat? They have no clue how to drive the car!

> If the user authorizes a piece of bad code, just de-authorize it and it dies.

That only tackles the problem of cleanup, which is a separate problem. By that time, the malware is already on the system and it's sent your credit card and documents to the bad guys.

"I don't understand how only allowing signed execution would help avoid this problem. Like you said, anyone could pay to get their company listed as a 'trusted' entity."

The purpose of signing isn't to guarantee that an entity is anything, but to allow the user to absolutely and decisively rule what code is allowed to execute. If the Russian Mob sneaks some code from "G0ogle, Ink." onto my machine by tricking me into authorizing that cert, I can just de-authorize it and then it all DIAF.

When I say signing, I don't necessarily mean the app store feudal model. I mean an inverted version of that -- where the user decides what runs by approving certs by signing them with some kind of master key.

"Poof, no more program debuggers, profilers, no more device drivers, no more third party file systems, no more"

You can debug Java pretty effectively. There are great toolchains for that. I agree that direct ASM may be required for a few things like drivers, but those are going to be the exceptions not the rule.

"How does that help my mom? She's just going to call me when the computer asks her "weird questions about keys and permissions"."

"Again, why would the user WANT to be in the drivers seat? They have no clue how to drive the car!"

Freedom and control are things you should have, but should not be forced to exercise. It should be possible to leave them alone and just trust one or more vendors. This is a UI/UX issue.

With things like iOS I don't have the option.

"That only tackles the problem of cleanup, which is a separate problem. By that time, the malware is already on the system and it's sent your credit card and documents to the bad guys."

Absolute security perfection isn't possible, but I think huge improvements can be made. Don't let the perfect be the enemy of the good.

Data leakage and social engineering are particularly thorny because they're really only half technical problems. The meat sack using the machine is always going to be a weak point in any security model. But if the machine were secure, it would help.

We're going around in circles I think.

The entire problem is that the users have no idea prior to installing the software, whether its legit or malware. I don't see anything in what you've proposed that solves the root problem. Yes, we can look at peripheral problems like cleanup and revoking certificates but those only affect users AFTER they've already made the choice of installing a particular piece of software.

The idea isn't to solve that problem, but to limit the damage significantly.

I should be able to give a Russian mob hacker on crack access to my machine without worrying too much about them doing anything I don't give them permission to do.

> We're going around in circles I think.

Just you, my friend. If you recall, here is the point you were challenging:

> this is a band-aid over the fact that OSes have terrible permission separation and application isolation. If OSes were better architected from a security point of view, it would be substantially less of a problem.

Would you now concede this point?

> If you recall, here is the point you were challenging:

Yes, and I didn't receive any information that would lead me to believe that applying his/her suggestions would substantially tackle the root problem. All process isolation does is push the problem out further into the application side of things. Now the user has to micromanage the data flow in between applications. The root problem has very little to do with OS architecture, and I'm happy to be convinced otherwise.

>Would you now concede this point?

Okay. If you insist. I have no desire to "win" the argument. It's merely idle chit chat for me. My code's compiling ;)

Reply on news.ycombinator.com