5 ms·

This is another reminder of why we should to move toward permissions sandboxing for individual libraries. Deno is a step in the right direction since it require

This is another reminder of why we should to move toward permissions sandboxing for individual libraries. Deno is a step in the right direction since it requires explicitly granting individual permissions for reading and writing the disk, but it currently does that at the program level rather than the library level.

cyber_kinetist 5y ago
Absolutely right, library-level permission systems are desperately needed, just like what Apple did with apps in iOS. The unfortunate thing is that these features aren’t at the OS level, and we need a separate runtime to do these kinds of things. The current widely used OS kernels (Windows, Linux) don’t give granular permissions that well, for example in Linux we either have all or nothing (root vs user). I’ve heard that OpenBSD has a system to constrain for each program what syscalls you can make, and Serenity is also following this model (https://awesomekling.github.io/pledge-and-unveil-in-SerenityOS/ https://awesomekling.github.io/pledge-and-unveil-in-Serenity...).
- epidemian 5y ago
  > in Linux we either have all or nothing (root vs user) And it's not like non-root user is nothing. I, as a user, can of course access and edit files on my $HOME directory. But it's insane that a transitive dependency of a dev dependency that has been installed without even my knowledge can have by default the same permissions to access and override any file on my $HOME directory.
- z3t4 5y ago
  Check out Apparmor and SELinux. You can for example make a profile for an app that says it can only access these files and write to these files, and forbid it to use the network. You can also start an app using the root user (or any user), but run setuid in the app (source code) in order to drop privileges. For example, first read secret key files, then drop privileges to a user that can't write anywhere - before running the rest of the code. This is common in web servers sunch as Nginx, you start with root, in order to read certificate keys, but the workers that accepts the requests and reads the files runs as the www user.
  - tetha 5y ago
    I severely wish for SELinux to have better documentation. I can and I have worked myself into dense and hard topics with little documentation, but SELinux is it's own thing. I can totally see how SELinux could improve the security of all our custom application servers a lot, and I think that's the case for pretty much all custom aplication servers - but it has taken months of thinking, reading sparse documentation, thinking about my linux knowledge to get some faint idea of how to implement a policy for a service. however, that's far from where I'd be confident to start this as an actual project. Given recent redhat stunts and our current infra switch, I hope AppArmor is less dense, or at least equipped with more approachable documentation.
    - z3t4 5y ago
      Alot can be done with SystemD (sandboxing)
    - z3t4 5y ago
      Apparmor has a nice learning curve, it's easy to get started with: sudo apt install apparmor-utils sudo aa-genprof /path/to/app Profiles are saved in /etc/apparmor.d/ Many apps need access to /dev/urandom, /usr/bin, /usr/lib and be able to send and receive hup and int signals from other programs. One nice thing is that you can define rules for child process spawned by your executable: /path/to/your/app/childprocessorscripts/** Cx -> scripts, profile scripts { ... } Unix sockets are very nice, prefer them over TCP/IP. For example if you have Nginx or other proxy, use Unix sockets instead of TCP/IP! network unix, Unix sockets allows you to set permissions per socket If your app needs to spawn something that use TCP: /usr/bin/curl px -> networkTool, profile networkTool { network, } Permission errors will show up in /var/log/kern.log You can find errors and edit profiles with aa-logprof If you get frustrated you can allow everything, but show logs: sudo aa-complain /path/to/app
  - journey_16162 5y ago
    I was not able to achieve what I wanted with Selinux. As far as I understand it, SeLinux is a blacklist approach, rather than whitelist. You can go far on Linux without SELinux, by making user accounts for specific applications and tasks. I.e. I have an account just for the browser so if I was affected by 0-day, it reduces the chances of the system being compromised. I have an account for JS projects, so if some npm module has a RAT in it (or deletes everything in the system), it would only be able to access the files in that specific-user directory.
nhoughto 5y ago
it would take a drastically differently designed execution environment to support meaningful library level sandboxing. After packaging/linking/bundling/compiling etc depending on language/flavour often a library is indistinguishable from 1st party code, there is no boundary to sandbox. Without a large scale change, you'd have to fork a new process for each 'library' to create a process boundary to then sandbox, which is actually what you do sometimes (think firing ffmpeg or openssl or similar) but doing it for each library would be prohibitive, especially in NPM world where you blink and have thousands of libraries =)
ryukafalz 5y ago
I’d argue we should go finer-grained than that even and use languages where following the principle of least privilege is natural. (JavaScript is close-ish and could become this language with some tweaks.) There’s often no reason the part of your program that e.g. handles untrusted network communication needs to be able to read and write arbitrary files on disk, but right now they can. But yes, library level authorization at the very least.

cyber_kinetist 5y ago

Absolutely right, library-level permission systems are desperately needed, just like what Apple did with apps in iOS. The unfortunate thing is that these features aren’t at the OS level, and we need a separate runtime to do these kinds of things. The current widely used OS kernels (Windows, Linux) don’t give granular permissions that well, for example in Linux we either have all or nothing (root vs user). I’ve heard that OpenBSD has a system to constrain for each program what syscalls you can make, and Serenity is also following this model (https://awesomekling.github.io/pledge-and-unveil-in-SerenityOS/ https://awesomekling.github.io/pledge-and-unveil-in-Serenity...).

epidemian 5y ago
> in Linux we either have all or nothing (root vs user) And it's not like non-root user is nothing. I, as a user, can of course access and edit files on my $HOME directory. But it's insane that a transitive dependency of a dev dependency that has been installed without even my knowledge can have by default the same permissions to access and override any file on my $HOME directory.
z3t4 5y ago
Check out Apparmor and SELinux. You can for example make a profile for an app that says it can only access these files and write to these files, and forbid it to use the network. You can also start an app using the root user (or any user), but run setuid in the app (source code) in order to drop privileges. For example, first read secret key files, then drop privileges to a user that can't write anywhere - before running the rest of the code. This is common in web servers sunch as Nginx, you start with root, in order to read certificate keys, but the workers that accepts the requests and reads the files runs as the www user.
- tetha 5y ago
  I severely wish for SELinux to have better documentation. I can and I have worked myself into dense and hard topics with little documentation, but SELinux is it's own thing. I can totally see how SELinux could improve the security of all our custom application servers a lot, and I think that's the case for pretty much all custom aplication servers - but it has taken months of thinking, reading sparse documentation, thinking about my linux knowledge to get some faint idea of how to implement a policy for a service. however, that's far from where I'd be confident to start this as an actual project. Given recent redhat stunts and our current infra switch, I hope AppArmor is less dense, or at least equipped with more approachable documentation.
  - z3t4 5y ago
    Alot can be done with SystemD (sandboxing)
  - z3t4 5y ago
    Apparmor has a nice learning curve, it's easy to get started with: sudo apt install apparmor-utils sudo aa-genprof /path/to/app Profiles are saved in /etc/apparmor.d/ Many apps need access to /dev/urandom, /usr/bin, /usr/lib and be able to send and receive hup and int signals from other programs. One nice thing is that you can define rules for child process spawned by your executable: /path/to/your/app/childprocessorscripts/** Cx -> scripts, profile scripts { ... } Unix sockets are very nice, prefer them over TCP/IP. For example if you have Nginx or other proxy, use Unix sockets instead of TCP/IP! network unix, Unix sockets allows you to set permissions per socket If your app needs to spawn something that use TCP: /usr/bin/curl px -> networkTool, profile networkTool { network, } Permission errors will show up in /var/log/kern.log You can find errors and edit profiles with aa-logprof If you get frustrated you can allow everything, but show logs: sudo aa-complain /path/to/app
- journey_16162 5y ago
  I was not able to achieve what I wanted with Selinux. As far as I understand it, SeLinux is a blacklist approach, rather than whitelist. You can go far on Linux without SELinux, by making user accounts for specific applications and tasks. I.e. I have an account just for the browser so if I was affected by 0-day, it reduces the chances of the system being compromised. I have an account for JS projects, so if some npm module has a RAT in it (or deletes everything in the system), it would only be able to access the files in that specific-user directory.

nhoughto 5y ago

it would take a drastically differently designed execution environment to support meaningful library level sandboxing. After packaging/linking/bundling/compiling etc depending on language/flavour often a library is indistinguishable from 1st party code, there is no boundary to sandbox. Without a large scale change, you'd have to fork a new process for each 'library' to create a process boundary to then sandbox, which is actually what you do sometimes (think firing ffmpeg or openssl or similar) but doing it for each library would be prohibitive, especially in NPM world where you blink and have thousands of libraries =)

ryukafalz 5y ago

I’d argue we should go finer-grained than that even and use languages where following the principle of least privilege is natural. (JavaScript is close-ish and could become this language with some tweaks.) There’s often no reason the part of your program that e.g. handles untrusted network communication needs to be able to read and write arbitrary files on disk, but right now they can. But yes, library level authorization at the very least.