4 ms·

Agreed, Linux is way behind in kernel and userland hardening. Things are slowly getting better, with some of grsec/PaX's features being merged upstream [0] and

by totony 6y ago

Agreed, Linux is way behind in kernel and userland hardening. Things are slowly getting better, with some of grsec/PaX's features being merged upstream [0] and X being slowly replaced by wayland (but it still has issues before mass adoption). SELinux/Apparmor fix some issues, but their policies are not restrictive enough (and when they are, they get disabled because they're too user-unfriendly). Android did a good job integrating SELinux in their ecosystem to provide some sort of sandbox, I wish there were similar project for desktop Linux, but it seems only Redhat cares about SELinux in the OSS world (and they don't seem to have this kind of project in the works). sudo is Linux's UAC, and I agree that it is insecure, but its use is optional and with good selinux policies, you shouldn't be able to highjack it like in the OP (unfortunately, there are no good, easy-to-use selinux policies) Linux has too big an attack surface IMO and I wish microkernels like GNU/Hurd or seL4 would become more popular, but, like most things in OSS, there are not enough people interested. [0] https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...

gizmo686 6y ago
Much of my job is based on writing SELinux policy. The problem is that SELinux is not well suited to the needs of a desktop environment. Consider a web browser. Ideally, it should not be able to read any local files (except its own). But sometimes, users want to use web browsers on local files; and sometimes users want to save/download web resources to arbitrary locations, so you end up needing to give browsers those permissions anyway. Redhat's approach is a targeted policy. Users and user applications run in an unconfined domain, while system and services run in a secured domain. Android uses a similar approach where SELinux provides system level protection (as well as application level isolation). However, the security model most people (even Android app developers) are familiar with is not SELinux. The difference between an app that has permission to use the microphone and one that does not is not SELinux. It is implemented by a userspace security manager. I am not fammilar with Apparmor, but I do not see how any solution based on the Linux kernel's security module system would be adequate. The type of security needed for a desktop system requires a lot of userspace work.
- guenthert 6y ago
  > But sometimes, users want to use web browsers on local files Well, that's just risky computer usage. I'd think it's a reasonable compromise, if users would copy files into a specific up/download folder for the web browser to access. Such can be enforced with, e.g. firejail. Clearly this is slightly inconvenient, but security has always been at odds with convenience and always will be.
  - totony 6y ago
    I've done this and it is quite the hassle imo
- totony 6y ago
  I've experience this too while writing policies, but firefox could open an unconfined file manager which is like a "selinux setuid", where it asks the user what to do and change the mcs level of a file until it is written to/read. I don't think this is unsolvable. Edit: actually, that file manager could pass an open fd to firefox, I'm not sure how that would work policy-wise
  - totony 6y ago
    Or maybe a hook could be added to the kernel in the looks of "if mozilla_t is denied access to user_home_t, execute /usr/bin/notify and if it returns 0 allow it for this time"
    - gizmo686 6y ago
      You can kind of do that already using SELinux booleans. In policy, have something like: if (mozilla_read_user_home) { allow mozilla_t user_home_t:file read_file_perms; } Then, firefox could execute /usr/bin/request_file_access user_home_t read request_file_access could then be spawned in a privileged domain and: 1) Check the domain of the parent process and see that it is mozilla_t 2) Check whatever security policy it wants to implement (possibly by prompting the user) 3) Assuming the access is allowed, set the mozilla_read_user_home variable to true (and set a timer to disable it at some point in the future) 4) firefox then can open the file normally. Keep in mind that denials actually happen quite frequently on many SELinux systems, and policy is usualy written to not even log the expected ones. Any hook that needs to run on every denial would likely introduce unacceptable performance hits; particuarly if it needs to spawn another process.

by totony 6y ago

gizmo686 6y ago

Much of my job is based on writing SELinux policy. The problem is that SELinux is not well suited to the needs of a desktop environment. Consider a web browser. Ideally, it should not be able to read any local files (except its own). But sometimes, users want to use web browsers on local files; and sometimes users want to save/download web resources to arbitrary locations, so you end up needing to give browsers those permissions anyway. Redhat's approach is a targeted policy. Users and user applications run in an unconfined domain, while system and services run in a secured domain. Android uses a similar approach where SELinux provides system level protection (as well as application level isolation). However, the security model most people (even Android app developers) are familiar with is not SELinux. The difference between an app that has permission to use the microphone and one that does not is not SELinux. It is implemented by a userspace security manager. I am not fammilar with Apparmor, but I do not see how any solution based on the Linux kernel's security module system would be adequate. The type of security needed for a desktop system requires a lot of userspace work.

guenthert 6y ago
> But sometimes, users want to use web browsers on local files Well, that's just risky computer usage. I'd think it's a reasonable compromise, if users would copy files into a specific up/download folder for the web browser to access. Such can be enforced with, e.g. firejail. Clearly this is slightly inconvenient, but security has always been at odds with convenience and always will be.
- totony 6y ago
  I've done this and it is quite the hassle imo
totony 6y ago
I've experience this too while writing policies, but firefox could open an unconfined file manager which is like a "selinux setuid", where it asks the user what to do and change the mcs level of a file until it is written to/read. I don't think this is unsolvable. Edit: actually, that file manager could pass an open fd to firefox, I'm not sure how that would work policy-wise
- totony 6y ago
  Or maybe a hook could be added to the kernel in the looks of "if mozilla_t is denied access to user_home_t, execute /usr/bin/notify and if it returns 0 allow it for this time"
  - gizmo686 6y ago
    You can kind of do that already using SELinux booleans. In policy, have something like: if (mozilla_read_user_home) { allow mozilla_t user_home_t:file read_file_perms; } Then, firefox could execute /usr/bin/request_file_access user_home_t read request_file_access could then be spawned in a privileged domain and: 1) Check the domain of the parent process and see that it is mozilla_t 2) Check whatever security policy it wants to implement (possibly by prompting the user) 3) Assuming the access is allowed, set the mozilla_read_user_home variable to true (and set a timer to disable it at some point in the future) 4) firefox then can open the file normally. Keep in mind that denials actually happen quite frequently on many SELinux systems, and policy is usualy written to not even log the expected ones. Any hook that needs to run on every denial would likely introduce unacceptable performance hits; particuarly if it needs to spawn another process.