4 ms·

Are you suggesting that mkdir should know .ssh is special? I'm not sure that's a good idea. And how will the kernel (yes, it has to be the kernel) ask for a pas

by sdkmvx 13y ago

Are you suggesting that mkdir should know .ssh is special? I'm not sure that's a good idea. And how will the kernel (yes, it has to be the kernel) ask for a password when you access these files? With a GUI? On the console? So you don't want Firefox to be able to read SSH keys. Privilege separation and sandboxing is the correct solution to this problem. Full disk encryption will protect the data at rest.

malandrew 13y ago
No, I'm suggesting that the setup process for a new machine should include a step that creates .shh with mkdir and then uses chmod to set the permissions correctly, then possibly use another service daemon that boots on startup to watch for access to .ssh and manages showing you either terminal messages or GUI dialogs whenever any executable attempts to access anything in .ssh. I think firefox should be able to access SSH keys as should any other application, but I should be notified when this is going to happen. From there I should be able to trust an application indefinitely so long as it's executable doesn't change (i.e. maintain shasum hashes of any trusted executable and make sure that if the shasum changes, you are informed that it has changed. e.g. "The executable Foo has changed since you last trusted it, would you like to trust it again?" Privilege separation and sandboxing is the correct solution, but there is no reason that these cannot be improved upon to make this more friendly but still secure. Accepting the status quo solutions is akin to accepting that it will always remain a niche solution that never gains acceptance and traction in other areas of our lives where we want security and a solution that is inherently decentralized.
deckiedan 13y ago
Actually, a really good way to do this would be with a FUSE filesystem for such things. Then the kernel doesn't need to do anything at all. You could base it over the top of encFS or something like that. I'm actually really tempted to do that now...

by sdkmvx 13y ago

malandrew 13y ago

No, I'm suggesting that the setup process for a new machine should include a step that creates .shh with mkdir and then uses chmod to set the permissions correctly, then possibly use another service daemon that boots on startup to watch for access to .ssh and manages showing you either terminal messages or GUI dialogs whenever any executable attempts to access anything in .ssh. I think firefox should be able to access SSH keys as should any other application, but I should be notified when this is going to happen. From there I should be able to trust an application indefinitely so long as it's executable doesn't change (i.e. maintain shasum hashes of any trusted executable and make sure that if the shasum changes, you are informed that it has changed. e.g. "The executable Foo has changed since you last trusted it, would you like to trust it again?" Privilege separation and sandboxing is the correct solution, but there is no reason that these cannot be improved upon to make this more friendly but still secure. Accepting the status quo solutions is akin to accepting that it will always remain a niche solution that never gains acceptance and traction in other areas of our lives where we want security and a solution that is inherently decentralized.

deckiedan 13y ago

Actually, a really good way to do this would be with a FUSE filesystem for such things. Then the kernel doesn't need to do anything at all. You could base it over the top of encFS or something like that. I'm actually really tempted to do that now...