3 ms·

Why would an unprivileged app be allowed to make such changes?

by TwoBit 11y ago

geofft 11y ago
It's not (see my other reply), but for why it used to be allowed, it's because the traditional UNIX security boundary has been user accounts. Any process running as user id 1000 has the same permissions as any other process running as user id 1000, and so it's permitted to mess with those processes. It can't mess with user id 1001 or (of course) 0. But Minecraft running as uid 1000, Safari running as uid 1000, and bash running as uid 1000 are all considered as the same entity. In this model, the real problem here is sudo, which bridges a uid-1000 session to a uid-0 one. If you're administering a security-conscious, multi-user UNIX system, you should not be using sudo from your regular account. Either make a separate account and log in as that, or log in as root directly. (But if you want your Minecraft and your bash to not be able to interact with each other, the traditional approach doesn't have an answer for you.) Of course, most UNIX deployments today are not multi-user remote-access systems, the way they were 30+ years ago when this policy was set. Most desktop UNIX deployments are effectively single-user systems, and the UNIX isolation model doesn't make much sense there. As a stopgap measure, direct access to another process's memory has been disallowed, but there are other ways for processes that share UID to mess with each other. However, the most common single-user UNIX systems today are smartphones, either Android (Linux) or iOS (BSD + stuff). Android takes advantage of the UNIX model by assigning each app its own user ID. Angry Birds running as uid 1000 cannot mess with the Chase mobile app running as uid 1001. iOS technically runs all apps with the same uid, but applies extensive kernel-level sandboxing to limit the ways that apps can interact with the rest of the system, which essentially eliminates the rest of the leakiness. There's a Chromium security document that expands on the traditional "1-part principal" model (identity of the human) and how we need to get to "2-part principals" (identity of the human + identity of the app), which I hope that someone will figure out how to extend to desktop UNIX someday: https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features#TOC-Background- https://www.chromium.org/Home/chromium-security/prefer-secur...

Why would an unprivileged app be allowed to make such changes?

by TwoBit 11y ago

Why would an unprivileged app be allowed to make such changes?

It's not (see my other reply), but for why it used to be allowed, it's because the traditional UNIX security boundary has been user accounts. Any process running as user id 1000 has the same permissions as any other process running as user id 1000, and so it's permitted to mess with those processes. It can't mess with user id 1001 or (of course) 0. But Minecraft running as uid 1000, Safari running as uid 1000, and bash running as uid 1000 are all considered as the same entity. In this model, the real problem here is sudo, which bridges a uid-1000 session to a uid-0 one. If you're administering a security-conscious, multi-user UNIX system, you should not be using sudo from your regular account. Either make a separate account and log in as that, or log in as root directly. (But if you want your Minecraft and your bash to not be able to interact with each other, the traditional approach doesn't have an answer for you.) Of course, most UNIX deployments today are not multi-user remote-access systems, the way they were 30+ years ago when this policy was set. Most desktop UNIX deployments are effectively single-user systems, and the UNIX isolation model doesn't make much sense there. As a stopgap measure, direct access to another process's memory has been disallowed, but there are other ways for processes that share UID to mess with each other. However, the most common single-user UNIX systems today are smartphones, either Android (Linux) or iOS (BSD + stuff). Android takes advantage of the UNIX model by assigning each app its own user ID. Angry Birds running as uid 1000 cannot mess with the Chase mobile app running as uid 1001. iOS technically runs all apps with the same uid, but applies extensive kernel-level sandboxing to limit the ways that apps can interact with the rest of the system, which essentially eliminates the rest of the leakiness. There's a Chromium security document that expands on the traditional "1-part principal" model (identity of the human) and how we need to get to "2-part principals" (identity of the human + identity of the app), which I hope that someone will figure out how to extend to desktop UNIX someday: https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features#TOC-Background- https://www.chromium.org/Home/chromium-security/prefer-secur...