4 ms·

And I think it is rather obvious. Pledge lessens the amount of syscalls available to a program after it has called pledge(), so the threats it means to protect

by IcePic 6y ago

And I think it is rather obvious. Pledge lessens the amount of syscalls available to a program after it has called pledge(), so the threats it means to protect against is if someone tries to trick "ls" into opening a socket and doing network calls for instance, if ls pledges that from this point onward it will only do disk reads via the fs and output via text console. Just as a guide telling you to "chmod 600 webserver.key" doesn't really state anymore that it tries to protect non-webserver access to the https key, because it is implied that removing random access to the key (or to non-useful syscalls in the case of pledge) means the threat was unexpected reads of the key by someone who shouldn't be allowed to do just that. No assessments would be found to say "chmod'ing 600 removes 56% of the unexpected read attempts, Posix ACLs 9% more, apparmor another 14%, and correct SELinux tags will stop upto 96% of the keyfile reads by the wrong user". If my wildly invented numbers were right would anyone suggest only using SELinux and leave keyfiles at chmod 777? One can then put up an angry webpage claiming people who chmod their keys are crap at security, it is uneffective, no listing of what it even was meant to protect against and of course no hard numbers to it. But 0600 would help you the day some junior admin turned off selinux on the webserver because random HOWTO said colorls works better with it off.

lmm 6y ago
> Pledge lessens the amount of syscalls available to a program after it has called pledge(), so the threats it means to protect against is if someone tries to trick "ls" into opening a socket and doing network calls for instance, if ls pledges that from this point onward it will only do disk reads via the fs and output via text console. Does that improve security? By how much? What exploitation would it have prevented? At what cost? If you're not measuring the impact then it's pretty much voodoo security. > Just as a guide telling you to "chmod 600 webserver.key" doesn't really state anymore that it tries to protect non-webserver access to the https key, because it is implied that removing random access to the key (or to non-useful syscalls in the case of pledge) means the threat was unexpected reads of the key by someone who shouldn't be allowed to do just that. Then that guide is of little practical use. On a multi-user server that chmod makes sense. Inside a single-user container/VM, it's completely pointless. If the guide isn't telling you what the threat model is, you have no idea whether the mitigations you're applying are relevant or not. > No assessments would be found to say "chmod'ing 600 removes 56% of the unexpected read attempts, Posix ACLs 9% more, apparmor another 14%, and correct SELinux tags will stop upto 96% of the keyfile reads by the wrong user". If my wildly invented numbers were right would anyone suggest only using SELinux and leave keyfiles at chmod 777? Yes! Of course. Would you not? > But 0600 would help you the day some junior admin turned off selinux on the webserver because random HOWTO said colorls works better with it off. If you think that's a real danger then include it in your threat model. Maybe SELinux is harder to understand, or configure, or too many people have access to its settings. Maybe it's the opposite (I've seen junior admins chmodding everything to 777 many times, I've yet to see one turn SELinux off). Either way, you need to explain that so that people understand it, otherwise you're encouraging people to cargo cult their security practices.

by IcePic 6y ago

lmm 6y ago

> Pledge lessens the amount of syscalls available to a program after it has called pledge(), so the threats it means to protect against is if someone tries to trick "ls" into opening a socket and doing network calls for instance, if ls pledges that from this point onward it will only do disk reads via the fs and output via text console. Does that improve security? By how much? What exploitation would it have prevented? At what cost? If you're not measuring the impact then it's pretty much voodoo security. > Just as a guide telling you to "chmod 600 webserver.key" doesn't really state anymore that it tries to protect non-webserver access to the https key, because it is implied that removing random access to the key (or to non-useful syscalls in the case of pledge) means the threat was unexpected reads of the key by someone who shouldn't be allowed to do just that. Then that guide is of little practical use. On a multi-user server that chmod makes sense. Inside a single-user container/VM, it's completely pointless. If the guide isn't telling you what the threat model is, you have no idea whether the mitigations you're applying are relevant or not. > No assessments would be found to say "chmod'ing 600 removes 56% of the unexpected read attempts, Posix ACLs 9% more, apparmor another 14%, and correct SELinux tags will stop upto 96% of the keyfile reads by the wrong user". If my wildly invented numbers were right would anyone suggest only using SELinux and leave keyfiles at chmod 777? Yes! Of course. Would you not? > But 0600 would help you the day some junior admin turned off selinux on the webserver because random HOWTO said colorls works better with it off. If you think that's a real danger then include it in your threat model. Maybe SELinux is harder to understand, or configure, or too many people have access to its settings. Maybe it's the opposite (I've seen junior admins chmodding everything to 777 many times, I've yet to see one turn SELinux off). Either way, you need to explain that so that people understand it, otherwise you're encouraging people to cargo cult their security practices.