7 ms·

"Solid SELinux policy" is really the hard part there. When I pip install paramiko, I do, in fact, want it to have access to my SSH keys. When I pip install ans

by geofft 7y ago

"Solid SELinux policy" is really the hard part there. When I pip install paramiko, I do, in fact, want it to have access to my SSH keys. When I pip install ansible, I want ansible to be able to shell out to OpenSSH to use my keys. If I write custom Python code that calls gpg, I want that custom code to be able to load libraries that I've pip installed without the gpg subprocess being blocked from loading my keys. If I have a backup client in Python, and I tell it to back up my entire home directory, I want it backing up my entire home directory including private keys. If I wanted an OS where I couldn't install arbitrary code and have it get to all my files for my own good, I'd use iOS. (I do, in fact, use iOS on my phone because I sometimes want this. But when I'm writing Python code, I don't.) SELinux has been able to solve the problem of "if a policy says X can't get to Y, prevent X from getting to Y" for years. Regular UNIX permissions have been doing the same for decades. (Yes, SELinux and regular UNIX permissions take a different approach / let you write the policy differently, but that's the problem they're fundamentally solving; given a clear description of who to deny access to, deny this access.) Neither SELinux nor UNIX permissions nor anything else has solved the problem of "Actually, in this circumstance I mean for X to get to Y, but in that circumstance I don't, and this is obvious to a human but there's no clear programmable distinction between the cases." To be clear - I think there is potentially something of a hybrid approach between the status quo and what newer OSes do. For instance, imagine if each virtualenv were its own sandboxed environment (which could be "SELinux context" or could just be "UNIX user account") and so if you're writing code in one project, things you pip install have access to that code but not your whole user account. I'm just saying that SELinux hasn't magically solved this problem because all it provides is tools you could use to solve it, not a solution itself.

SEJeff 7y ago
An alternative solution is just sandboxing of user processes ala containers. Something kind of like what Qubes does: https://www.qubes-os.org/ https://www.qubes-os.org/ With a bit of work, the tech behind that could be made to work reasonably well in a general purpose linux distribution like say Fedora.
- Spivak 7y ago
  Shoving everything into namespaces doesn't solve everything because at the end of the day those 'containers' are still regular 'ole processes running in the root namespace under UIDs that are valid in the root namespace.
  - f38zf5vdt 7y ago
    Qubes instances are native virtualized via hardware-assisted virtualization, so there shouldn't be any ability for instances to access root UID processes unless the hardware virtualization solution's security fails (Intel's cache/branch prediction attacks).
  - xj9 7y ago
    that's a problem with linux not taking container security seriously. there are other, more secure, container implementations in different kernels. containers are a good abstraction, but linux does them poorly.
vageli 7y ago
> SELinux has been able to solve the problem of "if a policy says X can't get to Y, prevent X from getting to Y" for years. Regular UNIX permissions have been doing the same for decades. (Yes, SELinux and regular UNIX permissions take a different approach / let you write the policy differently, but that's the problem they're fundamentally solving; given a clear description of who to deny access to, deny this access.) Neither SELinux nor UNIX permissions nor anything else has solved the problem of "Actually, in this circumstance I mean for X to get to Y, but in that circumstance I don't, and this is obvious to a human but there's no clear programmable distinction between the cases." I don't think even your examples are obvious to everyone. For example, if paramiko is installed as a dependency of something else, it's not clear that you want to grant it access to your keys. Further, you might want to grant access to some but not all keys. There are many nuances that are unique to the particular use case which I don't think are obvious. However, that doesn't explain the inability of tools to allow us to describe these relationships.
- greggman2 7y ago
  Is it possible the OS should be designed so only the OS can read the actual private key so then at least at some level some apps don't ever need to see the key, they just need permission to authenticate.
  - geofft 7y ago
    As described in a sibling thread, while that contains the damage, that doesn't actually solve the problem - you're still giving malicious code permission to authenticate.
Spivak 7y ago
The value-add for SELinux is that the security boundary is no longer the user. Prior to SELinux a process running as `bob` is allowed to access anything that Bob himself can access. It at least pushes the boundary to I want to allow X program to access Y instead of I want to allow X user to access Y. Using a user account per-app only really works elegantly on single user systems where there are a small number of apps. bob-firefox, bob-vim, alice-evolution, alice-calculator,... would be a nightmare to maintain compared to being able to apply policy to the program itself.
- geofft 7y ago
  > bob-firefox, bob-vim, alice-evolution, alice-calculator,... would be a nightmare to maintain compared to being able to apply policy to the program itself. This is how Android works, btw. Each app has its own UID. And the standard SELinux policies don't solve this problem, anyway - when there are a small number of apps, you can give them each a context, but maintaining one for hundreds or thousands of apps is a nightmare. For web serving itself, quoting from https://linux.die.net/man/8/httpd_selinux https://linux.die.net/man/8/httpd_selinux : The following process types are defined for httpd:* httpd_cvs_script_t, httpd_rotatelogs_t, httpd_bugzilla_script_t, httpd_smokeping_cgi_script_t, httpd_nagios_script_t, httpd_dirsrvadmin_script_t, httpd_suexec_t, httpd_php_t, httpd_w3c_validator_script_t, httpd_user_script_t, httpd_awstats_script_t, httpd_apcupsd_cgi_script_t, httpd_nutups_cgi_script_t, httpd_munin_script_t, httpd_openshift_script_t, httpd_sys_script_t, httpd_dspam_script_t, httpd_prewikka_script_t, httpd_git_script_t, httpd_unconfined_script_t, httpd_t, httpd_helper_t, httpd_squid_script_t, httpd_cobbler_script_t, httpd_mediawiki_script_t* SELinux works elegantly on a very lightly configured system where there are a small number of apps and you got them all from the distro.
mikepurvis 7y ago
One nice thing about a virtualenv is that you get a copy of the Python interpreter in there, so it is in fact a separate executable running, for the purposes of hanging the policies off of.
- more-coffee 7y ago
  Depending on the platform, virtualenv defaults to creating a symlink to the Python executable. You can override it with --copies, but then you have a new problem: updating the interpreter in all virtualenvs when a new Python release comes out.
  - mikepurvis 7y ago
    On Ubuntu 16.04, the default behaviour is definitely to copy it, and there are no tricks with hardlinks or anything else: $ virtualenv foo Running virtualenv with interpreter /usr/bin/python2 New python executable in /home/administrator/foo/bin/python2 Also creating executable in /home/administrator/foo/bin/python Installing setuptools, pkg_resources, pip, wheel...done. $ ls -la foo/bin total 3464 drwxrwxr-x 2 administrator administrator 4096 Dec 4 11:06 . drwxrwxr-x 7 administrator administrator 4096 Dec 4 11:06 .. -rw-rw-r-- 1 administrator administrator 2082 Dec 4 11:06 activate -rw-rw-r-- 1 administrator administrator 1024 Dec 4 11:06 activate.csh -rw-rw-r-- 1 administrator administrator 2222 Dec 4 11:06 activate.fish -rw-rw-r-- 1 administrator administrator 1137 Dec 4 11:06 activate_this.py -rwxrwxr-x 1 administrator administrator 252 Dec 4 11:06 easy_install -rwxrwxr-x 1 administrator administrator 252 Dec 4 11:06 easy_install-2.7 -rwxrwxr-x 1 administrator administrator 239 Dec 4 11:06 pip -rwxrwxr-x 1 administrator administrator 239 Dec 4 11:06 pip2 -rwxrwxr-x 1 administrator administrator 239 Dec 4 11:06 pip2.7 lrwxrwxrwx 1 administrator administrator 7 Dec 4 11:06 python -> python2 -rwxrwxr-x 1 administrator administrator 3492656 Dec 4 11:06 python2 lrwxrwxrwx 1 administrator administrator 7 Dec 4 11:06 python2.7 -> python2 -rwxrwxr-x 1 administrator administrator 2341 Dec 4 11:06 python-config -rwxrwxr-x 1 administrator administrator 230 Dec 4 11:06 wheel This is with virtualenv 15.0.1.
tialaramex 7y ago
> When I pip install paramiko, I do, in fact, want it to have access to my SSH keys Do you? Wouldn't it be better if Paramiko was obliged to access your keys via the agent? Then we could secure the agent (there's more work to be done here anyway) and also it fixes problems where Paramiko wants to do something that the agent could facilitate (and so works with plain ssh) but Paramiko doesn't know about yet, like using a FIDO device to get a key. One of the obvious things the agent could do on a workstation is mention that your keys are being used. Imagine you run a job, which reaches out via Paramiko to fifteen servers, you see a brief notification saying the agent signed 15 logins for Paramiko. That makes sense. An hour later, reading the TPS reports, the agent notifies you again, Paramiko just signed another login. Huh? Now you're triggered to investigate what happened and why instead of it just silently happening and you read a press piece in a month about how a new version of Paramiko is off-siting your keys because bad guys broke into a GitHub repo or whatever.
- MadWombat 7y ago
  > Wouldn't it be better if Paramiko was obliged to access your keys via the agent? That's just kicking the can down the road. You get the same exact problem, but with the agent permissions rather than the actual keys. The problem is "I installed paramiko and I know what it does and I want it to access my SSH credentials, but I don't want evillib123 to access my SSH credentials even though I have installed it as well and I think I know what it does, but I am mistaken" and the distinction between the two cases above is in the intent and judging intent is hard. > One of the obvious things the agent could do on a workstation is mention that your keys are being used This has been tried many times. Windows UAC is one of the more ubiquitous and notorious examples. If everything starts sending you notifications you stop paying attention to them. That is what happened to UAC, it would notify users about important things, software installs, system setting changes, admin accesses etc. but it was doing it too much and most people would just click through without actually reading what the notification is about. And the reason it was doing it too much is because it cannot judge intent. It cannot tell the difference between me installing an application deliberately and me installing an application because I was tricked into it somehow.
  - 7y ago
marcus_holmes 7y ago
This is why I don't think this is an OS problem. I think it's a developer mindset problem. Dependencies are bad. Every single dependency in your code is a liability, a security loophole, a potential legal risk, and a time sink. Every dependency needs to be audited and evaluated, and all the changes on every update reviewed. Otherwise who knows what got injected into your code? Evaluating each dependency for potential risk is important. How much coding time is this saving? Would it, in fact, be quicker to just write that code yourself? Can you vendor it and cut out features you don't need? How many other people use this? Is it supported by its original maintainer? Does it have a deep-pocketed maintainer that could be an alternative target for legal claims? Mostly, people don't do that and just "import antigravity" without wondering if there's a free lunch in there...
- greggman2 7y ago
  That sounds like a boil the ocean solution. We're never going to get all developers to be perfect, and besides there are evil devs as well so the solution has to be elsewhere.
  - marcus_holmes 7y ago
    Well, where, exactly? The solution most people seem to be talking about is sandboxing imports off into containers (sandboxes, whatever - these will end up as containers) so that they can have their access to sensitive data and API's controlled. These aren't "code dependencies" any more, these are "runtime services". It implicitly conforms to "dependencies are bad" by forcing all dependencies to be external services. But it doesn't allow you to actually import known-good dependencies from trusted sources. And specifically granting access permissions to code has always worked before, right? I mean, people never just click "allow" all the time so they're not bothered by security dialogs, do they? Why are we talking about implementing such a proven-bad solution yet again?
    - danShumway 7y ago
      > And specifically granting access permissions to code has always worked before, right? I mean, people never just click "allow" all the time so they're not bothered by security dialogs, do they? Why are we talking about implementing such a proven-bad solution yet again? To be clear, is your argument that it's too hard for us to teach people to avoid granting unnecessary permissions, but not too hard for us to teach users not to install any software in the first place? Educating users about permissions is hard, convincing users not to download anything is impossible.
ozim 7y ago
If you are installing paramiko or ansible you know what you are doing. It should be end user conscious choice to give them access. You should not be prevented to give that access but also that access should not be granted without end user knowing it. You don't want to instal "some library, from somewhere" to have automatically access to everything on your machine. I also agree with all people that comment that it is solved problem in technical means. I someone installs random stuff it is like crossing street with closed eyes, you might not get hit by a car, but yeah chances are much higher then if you take your time and look around what you are doing.
- dredmorbius 7y ago
  The assumption that all users know what all processes, tools, or facilities are doing, at all times, and at all instances, has proved false far too many times. You could argue that the user should know what they're doing, but then, drivers shouldn't crash cars, and pilots shouldn't crash aircraft. Numerous elements of this problem are simply hard, perhaps impossible to resolve. If the problem is what Neal Stephonson called metaphor shear in "In the Beginning Was the Command Line", then the fundamental problem isn't technical, but that people generally are operating under a false mental model of what computers are, can do, and do behave. Yes, "all models are false, some are useful". The utility of this one may be past its sell-by date.
- mark-r 7y ago
  That approach has two problems. First is that access isn't fine-grained enough - you often have to grant access to far more than you intend. Second is that there's no way to know why an app is asking for access, or to be certain what it's going to do with that access.
saalweachter 7y ago
Without absolving us all of our responsibility to do better, to create systems that minimize the potential damage by bad actors, "I want to be able to download and execute random code off the internet and have it access my file system, my cameras, my network, my everything, but only in ways that don't hurt me", has always been kind of a pipe dream. It's also kind of hilarious when the person downloading and executing random code off the internet isn't the naive user, the pointy haired boss, the stereotypical grandmother, the dumb tween, but the "sophisticated", computer-savvy, net-wise programmers.

by geofft 7y ago

SEJeff 7y ago

An alternative solution is just sandboxing of user processes ala containers. Something kind of like what Qubes does: https://www.qubes-os.org/ https://www.qubes-os.org/ With a bit of work, the tech behind that could be made to work reasonably well in a general purpose linux distribution like say Fedora.

Spivak 7y ago
Shoving everything into namespaces doesn't solve everything because at the end of the day those 'containers' are still regular 'ole processes running in the root namespace under UIDs that are valid in the root namespace.
- f38zf5vdt 7y ago
  Qubes instances are native virtualized via hardware-assisted virtualization, so there shouldn't be any ability for instances to access root UID processes unless the hardware virtualization solution's security fails (Intel's cache/branch prediction attacks).
- xj9 7y ago
  that's a problem with linux not taking container security seriously. there are other, more secure, container implementations in different kernels. containers are a good abstraction, but linux does them poorly.

vageli 7y ago

> SELinux has been able to solve the problem of "if a policy says X can't get to Y, prevent X from getting to Y" for years. Regular UNIX permissions have been doing the same for decades. (Yes, SELinux and regular UNIX permissions take a different approach / let you write the policy differently, but that's the problem they're fundamentally solving; given a clear description of who to deny access to, deny this access.) Neither SELinux nor UNIX permissions nor anything else has solved the problem of "Actually, in this circumstance I mean for X to get to Y, but in that circumstance I don't, and this is obvious to a human but there's no clear programmable distinction between the cases." I don't think even your examples are obvious to everyone. For example, if paramiko is installed as a dependency of something else, it's not clear that you want to grant it access to your keys. Further, you might want to grant access to some but not all keys. There are many nuances that are unique to the particular use case which I don't think are obvious. However, that doesn't explain the inability of tools to allow us to describe these relationships.

greggman2 7y ago
Is it possible the OS should be designed so only the OS can read the actual private key so then at least at some level some apps don't ever need to see the key, they just need permission to authenticate.
- geofft 7y ago
  As described in a sibling thread, while that contains the damage, that doesn't actually solve the problem - you're still giving malicious code permission to authenticate.

Spivak 7y ago

The value-add for SELinux is that the security boundary is no longer the user. Prior to SELinux a process running as `bob` is allowed to access anything that Bob himself can access. It at least pushes the boundary to I want to allow X program to access Y instead of I want to allow X user to access Y. Using a user account per-app only really works elegantly on single user systems where there are a small number of apps. bob-firefox, bob-vim, alice-evolution, alice-calculator,... would be a nightmare to maintain compared to being able to apply policy to the program itself.

geofft 7y ago
> bob-firefox, bob-vim, alice-evolution, alice-calculator,... would be a nightmare to maintain compared to being able to apply policy to the program itself. This is how Android works, btw. Each app has its own UID. And the standard SELinux policies don't solve this problem, anyway - when there are a small number of apps, you can give them each a context, but maintaining one for hundreds or thousands of apps is a nightmare. For web serving itself, quoting from https://linux.die.net/man/8/httpd_selinux https://linux.die.net/man/8/httpd_selinux : The following process types are defined for httpd:* httpd_cvs_script_t, httpd_rotatelogs_t, httpd_bugzilla_script_t, httpd_smokeping_cgi_script_t, httpd_nagios_script_t, httpd_dirsrvadmin_script_t, httpd_suexec_t, httpd_php_t, httpd_w3c_validator_script_t, httpd_user_script_t, httpd_awstats_script_t, httpd_apcupsd_cgi_script_t, httpd_nutups_cgi_script_t, httpd_munin_script_t, httpd_openshift_script_t, httpd_sys_script_t, httpd_dspam_script_t, httpd_prewikka_script_t, httpd_git_script_t, httpd_unconfined_script_t, httpd_t, httpd_helper_t, httpd_squid_script_t, httpd_cobbler_script_t, httpd_mediawiki_script_t* SELinux works elegantly on a very lightly configured system where there are a small number of apps and you got them all from the distro.

mikepurvis 7y ago

One nice thing about a virtualenv is that you get a copy of the Python interpreter in there, so it is in fact a separate executable running, for the purposes of hanging the policies off of.

more-coffee 7y ago
Depending on the platform, virtualenv defaults to creating a symlink to the Python executable. You can override it with --copies, but then you have a new problem: updating the interpreter in all virtualenvs when a new Python release comes out.
- mikepurvis 7y ago
  On Ubuntu 16.04, the default behaviour is definitely to copy it, and there are no tricks with hardlinks or anything else: $ virtualenv foo Running virtualenv with interpreter /usr/bin/python2 New python executable in /home/administrator/foo/bin/python2 Also creating executable in /home/administrator/foo/bin/python Installing setuptools, pkg_resources, pip, wheel...done. $ ls -la foo/bin total 3464 drwxrwxr-x 2 administrator administrator 4096 Dec 4 11:06 . drwxrwxr-x 7 administrator administrator 4096 Dec 4 11:06 .. -rw-rw-r-- 1 administrator administrator 2082 Dec 4 11:06 activate -rw-rw-r-- 1 administrator administrator 1024 Dec 4 11:06 activate.csh -rw-rw-r-- 1 administrator administrator 2222 Dec 4 11:06 activate.fish -rw-rw-r-- 1 administrator administrator 1137 Dec 4 11:06 activate_this.py -rwxrwxr-x 1 administrator administrator 252 Dec 4 11:06 easy_install -rwxrwxr-x 1 administrator administrator 252 Dec 4 11:06 easy_install-2.7 -rwxrwxr-x 1 administrator administrator 239 Dec 4 11:06 pip -rwxrwxr-x 1 administrator administrator 239 Dec 4 11:06 pip2 -rwxrwxr-x 1 administrator administrator 239 Dec 4 11:06 pip2.7 lrwxrwxrwx 1 administrator administrator 7 Dec 4 11:06 python -> python2 -rwxrwxr-x 1 administrator administrator 3492656 Dec 4 11:06 python2 lrwxrwxrwx 1 administrator administrator 7 Dec 4 11:06 python2.7 -> python2 -rwxrwxr-x 1 administrator administrator 2341 Dec 4 11:06 python-config -rwxrwxr-x 1 administrator administrator 230 Dec 4 11:06 wheel This is with virtualenv 15.0.1.

tialaramex 7y ago

> When I pip install paramiko, I do, in fact, want it to have access to my SSH keys Do you? Wouldn't it be better if Paramiko was obliged to access your keys via the agent? Then we could secure the agent (there's more work to be done here anyway) and also it fixes problems where Paramiko wants to do something that the agent could facilitate (and so works with plain ssh) but Paramiko doesn't know about yet, like using a FIDO device to get a key. One of the obvious things the agent could do on a workstation is mention that your keys are being used. Imagine you run a job, which reaches out via Paramiko to fifteen servers, you see a brief notification saying the agent signed 15 logins for Paramiko. That makes sense. An hour later, reading the TPS reports, the agent notifies you again, Paramiko just signed another login. Huh? Now you're triggered to investigate what happened and why instead of it just silently happening and you read a press piece in a month about how a new version of Paramiko is off-siting your keys because bad guys broke into a GitHub repo or whatever.

MadWombat 7y ago
> Wouldn't it be better if Paramiko was obliged to access your keys via the agent? That's just kicking the can down the road. You get the same exact problem, but with the agent permissions rather than the actual keys. The problem is "I installed paramiko and I know what it does and I want it to access my SSH credentials, but I don't want evillib123 to access my SSH credentials even though I have installed it as well and I think I know what it does, but I am mistaken" and the distinction between the two cases above is in the intent and judging intent is hard. > One of the obvious things the agent could do on a workstation is mention that your keys are being used This has been tried many times. Windows UAC is one of the more ubiquitous and notorious examples. If everything starts sending you notifications you stop paying attention to them. That is what happened to UAC, it would notify users about important things, software installs, system setting changes, admin accesses etc. but it was doing it too much and most people would just click through without actually reading what the notification is about. And the reason it was doing it too much is because it cannot judge intent. It cannot tell the difference between me installing an application deliberately and me installing an application because I was tricked into it somehow.
- 7y ago

marcus_holmes 7y ago

This is why I don't think this is an OS problem. I think it's a developer mindset problem. Dependencies are bad. Every single dependency in your code is a liability, a security loophole, a potential legal risk, and a time sink. Every dependency needs to be audited and evaluated, and all the changes on every update reviewed. Otherwise who knows what got injected into your code? Evaluating each dependency for potential risk is important. How much coding time is this saving? Would it, in fact, be quicker to just write that code yourself? Can you vendor it and cut out features you don't need? How many other people use this? Is it supported by its original maintainer? Does it have a deep-pocketed maintainer that could be an alternative target for legal claims? Mostly, people don't do that and just "import antigravity" without wondering if there's a free lunch in there...

greggman2 7y ago
That sounds like a boil the ocean solution. We're never going to get all developers to be perfect, and besides there are evil devs as well so the solution has to be elsewhere.
- marcus_holmes 7y ago
  Well, where, exactly? The solution most people seem to be talking about is sandboxing imports off into containers (sandboxes, whatever - these will end up as containers) so that they can have their access to sensitive data and API's controlled. These aren't "code dependencies" any more, these are "runtime services". It implicitly conforms to "dependencies are bad" by forcing all dependencies to be external services. But it doesn't allow you to actually import known-good dependencies from trusted sources. And specifically granting access permissions to code has always worked before, right? I mean, people never just click "allow" all the time so they're not bothered by security dialogs, do they? Why are we talking about implementing such a proven-bad solution yet again?
  - danShumway 7y ago
    > And specifically granting access permissions to code has always worked before, right? I mean, people never just click "allow" all the time so they're not bothered by security dialogs, do they? Why are we talking about implementing such a proven-bad solution yet again? To be clear, is your argument that it's too hard for us to teach people to avoid granting unnecessary permissions, but not too hard for us to teach users not to install any software in the first place? Educating users about permissions is hard, convincing users not to download anything is impossible.

ozim 7y ago

If you are installing paramiko or ansible you know what you are doing. It should be end user conscious choice to give them access. You should not be prevented to give that access but also that access should not be granted without end user knowing it. You don't want to instal "some library, from somewhere" to have automatically access to everything on your machine. I also agree with all people that comment that it is solved problem in technical means. I someone installs random stuff it is like crossing street with closed eyes, you might not get hit by a car, but yeah chances are much higher then if you take your time and look around what you are doing.

dredmorbius 7y ago
The assumption that all users know what all processes, tools, or facilities are doing, at all times, and at all instances, has proved false far too many times. You could argue that the user should know what they're doing, but then, drivers shouldn't crash cars, and pilots shouldn't crash aircraft. Numerous elements of this problem are simply hard, perhaps impossible to resolve. If the problem is what Neal Stephonson called metaphor shear in "In the Beginning Was the Command Line", then the fundamental problem isn't technical, but that people generally are operating under a false mental model of what computers are, can do, and do behave. Yes, "all models are false, some are useful". The utility of this one may be past its sell-by date.
mark-r 7y ago
That approach has two problems. First is that access isn't fine-grained enough - you often have to grant access to far more than you intend. Second is that there's no way to know why an app is asking for access, or to be certain what it's going to do with that access.

saalweachter 7y ago

Without absolving us all of our responsibility to do better, to create systems that minimize the potential damage by bad actors, "I want to be able to download and execute random code off the internet and have it access my file system, my cameras, my network, my everything, but only in ways that don't hurt me", has always been kind of a pipe dream. It's also kind of hilarious when the person downloading and executing random code off the internet isn't the naive user, the pointy haired boss, the stereotypical grandmother, the dumb tween, but the "sophisticated", computer-savvy, net-wise programmers.