4 ms·

> The (common) security model of GNU/Linux is for today/2020 in my opinion pretty bad for desktops and totally unacceptable for phones. Would you please expand

by lelele 6y ago

> The (common) security model of GNU/Linux is for today/2020 in my opinion pretty bad for desktops and totally unacceptable for phones. Would you please expand on this for desktops? or reference any kind of document? Thank you.

Zak 6y ago
I'm not the one you asked, but I think the underlying issue is that the Unix security model is built around the assumption that software shares the user's intent, and is treated as exactly as trusted as the user. Computers at the time tended to be multi-user, so the focus was on protecting users from other users. While there was a risk of overtly malicious software, preventing remote code execution attacks and teaching users not to run trojan horses was mostly sufficient (for Unix users; the broader population using Windows often installed malicious adware in the early 2000s). In a modern environment, software should not necessarily be trusted to act in accordance with the user's wishes or best interests, and there's often a financial incentive for software creators to do things users wouldn't want them to. In the early 2000s, the most visible issue was Windows software that displayed advertisements outside of the software, often not obviously connected to the software. It would often monitor the user's browsing habits and such, leading to the name "spyware". Spyware of that sort was universally considered malicious, but modern smartphone apps often send far more sensitive information, such as location and address books to their creators. Those provide a simple example of a situation the classic Unix security model doesn't address very well. I am the only user of my phone, and I obviously want to be able to read my address book and get my location from the GPS. I do not want the latest and greatest app for sharing pictures of my lunch to track my location to show me restaurant ads, and I only want it to know about people I have explicitly connected to within the app, not my whole address book. Android's security model addresses that to a degree, restricting some capabilities until the user explicitly allows them. Some of these, like filesystem access aren't handled very gracefully, and it's possible for an app to refuse to work until granted permissions it doesn't really need (this is against policy for inclusion in the Play store, but enforcement is imperfect, and software can be installed from other sources). One workaround seen in XPrivacy is to feed fake data to apps.
- nnt38 6y ago
  AFAIK XPrivacy needs root to be installed, which would break part of the android security model.
  - Zak 6y ago
    Not just root, but Xposed, which breaks the Android security model even more. Breakage isn't binary though. The user is still in charge of whether a given app gets access to root or Xposed features. The Android security model and additional security features of XPrivacy can be applied to apps the user does not trust with certain kinds of data or capabilities while granting other apps increased access.
dathinab 6y ago
Mostly what Zak says. All applications and (preferable system services too) should be sandbox fist. Linux has much sandbox technology but it's often focused on server use-cases, fairly complex and everything but sandbox first (more like non-sandbox first and then we fit the sandbox to make it so that the program doesn't notice it runs in one). But it's also many many small problems. Most (all?) of which you can solve by a complex combination of selinux + cgroups + ... + modified applications + ... (long list). But doing so it a lot of work and often ends up with major usability drawbacks. Just to name one example of a small but terrible feature: LD_PRELOAD. Sure it's nice for hot-fixes including ad-hoc security hardening but it's generally a horrible idea in a context where you don't fully trust all programs. Another think is that most programs can read conigs/settings of most other programs or at least know that there are such settings. And the list goes one. Again just to be clear you can fix a lot of this by putting things into Linux containers but what is missing is a container engine focused on desktop applications which goes far enough, which also entails you can't just run existing software without at least switching out the GTK/Qt framework with a version adapted for this use-case and potentially needing more adaption then this. So all technical possible but we are not quite there yet I think, but then I'm not completely sure as I haven't followed some of the underlying topics close enough in the recent years.

by lelele 6y ago

Zak 6y ago

I'm not the one you asked, but I think the underlying issue is that the Unix security model is built around the assumption that software shares the user's intent, and is treated as exactly as trusted as the user. Computers at the time tended to be multi-user, so the focus was on protecting users from other users. While there was a risk of overtly malicious software, preventing remote code execution attacks and teaching users not to run trojan horses was mostly sufficient (for Unix users; the broader population using Windows often installed malicious adware in the early 2000s). In a modern environment, software should not necessarily be trusted to act in accordance with the user's wishes or best interests, and there's often a financial incentive for software creators to do things users wouldn't want them to. In the early 2000s, the most visible issue was Windows software that displayed advertisements outside of the software, often not obviously connected to the software. It would often monitor the user's browsing habits and such, leading to the name "spyware". Spyware of that sort was universally considered malicious, but modern smartphone apps often send far more sensitive information, such as location and address books to their creators. Those provide a simple example of a situation the classic Unix security model doesn't address very well. I am the only user of my phone, and I obviously want to be able to read my address book and get my location from the GPS. I do not want the latest and greatest app for sharing pictures of my lunch to track my location to show me restaurant ads, and I only want it to know about people I have explicitly connected to within the app, not my whole address book. Android's security model addresses that to a degree, restricting some capabilities until the user explicitly allows them. Some of these, like filesystem access aren't handled very gracefully, and it's possible for an app to refuse to work until granted permissions it doesn't really need (this is against policy for inclusion in the Play store, but enforcement is imperfect, and software can be installed from other sources). One workaround seen in XPrivacy is to feed fake data to apps.

nnt38 6y ago
AFAIK XPrivacy needs root to be installed, which would break part of the android security model.
- Zak 6y ago
  Not just root, but Xposed, which breaks the Android security model even more. Breakage isn't binary though. The user is still in charge of whether a given app gets access to root or Xposed features. The Android security model and additional security features of XPrivacy can be applied to apps the user does not trust with certain kinds of data or capabilities while granting other apps increased access.

dathinab 6y ago

Mostly what Zak says. All applications and (preferable system services too) should be sandbox fist. Linux has much sandbox technology but it's often focused on server use-cases, fairly complex and everything but sandbox first (more like non-sandbox first and then we fit the sandbox to make it so that the program doesn't notice it runs in one). But it's also many many small problems. Most (all?) of which you can solve by a complex combination of selinux + cgroups + ... + modified applications + ... (long list). But doing so it a lot of work and often ends up with major usability drawbacks. Just to name one example of a small but terrible feature: LD_PRELOAD. Sure it's nice for hot-fixes including ad-hoc security hardening but it's generally a horrible idea in a context where you don't fully trust all programs. Another think is that most programs can read conigs/settings of most other programs or at least know that there are such settings. And the list goes one. Again just to be clear you can fix a lot of this by putting things into Linux containers but what is missing is a container engine focused on desktop applications which goes far enough, which also entails you can't just run existing software without at least switching out the GTK/Qt framework with a version adapted for this use-case and potentially needing more adaption then this. So all technical possible but we are not quite there yet I think, but then I'm not completely sure as I haven't followed some of the underlying topics close enough in the recent years.