4 ms·

> Temporary Privileges is an example of a security theater. It does not change the attack surface in a threat model because it's not temporal. Has anyone ever s

> Temporary Privileges is an example of a security theater. It does not change the attack surface in a threat model because it's not temporal. Has anyone ever shown a practical evidence to support this idea? I agree. I think the benefit of this is quite low. If someone takes over your machine, things are lost anyways. If they take over your machine but for some reason cannot access your password manager (or so) or your 2fa to increase priviledges, you at least gain some time before the attack happens since the attacker has to wait - but it's not a major win. The only case where this really helps is if the attacker gains only temporary access to you (maybe a temporary vulnerability in the browser) but can't "persist" it. In that case, you can reduce the blast radius.

belter 3y ago
Are you aware that you can associate an EC2 instance profile on a temporary basis with a role? And attach and detach them via api or on a schedule? Because if you do that, and you hack the machine (Linux, Windows or Mac not relevant...), but you don't have the role with the privileges you need, you are going nowhere. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_us...
- valenterry 3y ago
  Yeah, so that means the attacker has to wait for the next schedule. As I said, that's an advantage but I wouldn't classify it as a major win. It's different if you use a different machine for the priviledged account. Then an attacker has to take over that second machine too. IMHO this is a mucher better concept, but also increases friction significantly.
swores 3y ago
It also helps in large companies where lots of people may have needed the higher permissions over the years - if you do temporary permissions then someone currently/soon having those permissions needs to be hacked, as opposed to hacking any one of the many people who needed those permissions a few years ago and still have them because they weren't temporary and got forgotten about.
- valenterry 3y ago
  I think this is a different case though. The point of those "temporary priviledges" is not so that someone only can use them sometimes, it's that they only do use them sometimes. What you say (that people should only have the permissions that they need) is orthogonal to that.

belter 3y ago

Are you aware that you can associate an EC2 instance profile on a temporary basis with a role? And attach and detach them via api or on a schedule? Because if you do that, and you hack the machine (Linux, Windows or Mac not relevant...), but you don't have the role with the privileges you need, you are going nowhere. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_us...

valenterry 3y ago
Yeah, so that means the attacker has to wait for the next schedule. As I said, that's an advantage but I wouldn't classify it as a major win. It's different if you use a different machine for the priviledged account. Then an attacker has to take over that second machine too. IMHO this is a mucher better concept, but also increases friction significantly.

swores 3y ago

It also helps in large companies where lots of people may have needed the higher permissions over the years - if you do temporary permissions then someone currently/soon having those permissions needs to be hacked, as opposed to hacking any one of the many people who needed those permissions a few years ago and still have them because they weren't temporary and got forgotten about.

valenterry 3y ago
I think this is a different case though. The point of those "temporary priviledges" is not so that someone only can use them sometimes, it's that they only do use them sometimes. What you say (that people should only have the permissions that they need) is orthogonal to that.