5 ms·

If you are on a linux distro that supports apparmor (ubuntu/debian etc), such issues can be easily prevented by creating a sandbox profile and alias commands li

If you are on a linux distro that supports apparmor (ubuntu/debian etc), such issues can be easily prevented by creating a sandbox profile and alias commands like node/npm to run using it. alias npm='aa-exec -p sandbox npm' alias node='aa-exec -p sandbox node' sandbox profile: # /etc/apparmor.d/sandbox include <tunables/global> profile sandbox { #include <abstractions/base> #include <abstractions/consoles> #include <abstractions/nameservice> /sys/** r, /{usr/,}bin/* ixr, # nodejs install dir owner /home/*/nodejs/**/* rix, owner /tmp/** rw, owner /tmp/**/ rw, owner /home/*/.npm/_* lrw, owner /home/*/.npm/_*/ lrw, owner /home/*/.npm/_*/** lrw, owner /home/*/.npmrc r, owner /home/**/node_modules/ rwix, owner /home/**/node_modules/** rwix, owner /home/**/package.json rw, owner /home/**/package-lock.json rw, owner /home/*/projects/**/ r, owner /home/*/projects/** r, } To load the profile: sudo apparmor_parser -r /etc/apparmor.d/sandbox edit: For completeness, added step to load the profile.

kelnos 5y ago
I think you have a definition of "easily" that many might not subscribe to. If this policy isn't available and enabled by default in some package containing common policies, do you really expect your average developer to a) even know anything about AppArmor, or b) know how to write an AppArmor policy file without spending a few hours digging through docs, reading examples, and engaging in a bunch of trial and error? (If your answer is "yes" to either of those questions, I'd suggest you might overestimate what is common knowledge.)
- notpublic 5y ago
  Fair enough. I meant easy as in without installing any additional software, minimal config and ease of use. AppArmor has come a long way. It's worth learning about it. They have quite a few builtin profiles that you can take advantage of.
- BoorishBears 5y ago
  Only on HN can you use the word "easy" to describe a set of steps that follow directly after, and still end up having to clarify the word easy referred to your steps, not to the entire concept of the underlying technology.
  - dathinab 5y ago
    People mean the steps are not easy. Because it's now about copying them but being able to create them yourself on the fly for whatever you need.
    - BoorishBears 5y ago
      I really don't get what this is trying to say. Like, the tone of the comment makes no sense, the hard part isn't on the OP, and OP wasn't saying AppArmor is easy, just the content of their comment is easy (which it is!) It's like saying flipping a light switch to turn on a light is easy... the having someone fly in complaining that understanding industrial power generation is not easy at all.
      - varajelle 5y ago
        it's easy, just do 'rm rf /' My point is: how do we know the instructions are actually safe?
        BoorishBears 5y ago
        Oh brother. It's like wrestling a pig in the mud. If you don't trust it, don't run it... but I don't know how anyone in software development would be unable to function if they've never been able to trust someone else's config file suggestion.
      - dathinab 5y ago
        > content of their comment is easy (which it is!) It's not, it has subtle gaps in the sandbox which still allow some of the attacks it's supposedly protecting you from.
- Tommek 5y ago
  We reached a state where code monkeys believe they are developers. Of course you should know about the machine you are developing on.
  - theteapot 5y ago
    Nah. I agree with the other guy. AppArmour takes some time to learn and isn't super mainstream yet. At least it's a step forward from SELinux, but it still feels uncooked and adhoc to me.
  - vlovich123 5y ago
    There's an insane amount of tooling with varying degrees of overlap. You've got SELinux, BPF, seccomp, AppArmor as different approaches to security. Each of these takes quite a bit of dedicated time to master and most of them have lots of nuance & there can be overlap depending on what you're trying to secure. In a work environment, I'd typically outsource this to security engineers/experts OR spend my time learning those things for what I need them for - knowing the tools are out there are sufficient starting points for research when I need that knowledge. None of this applies to maintaining my development machine. You might want to revisit your gate keeping.
    - fartcannon 5y ago
      Im not a developer, but in the field I work in, a couple hours dedicated to learning a tool that would help you isnt much of an ask. And the little demo script GP wrote seems pretty straight forward to me.
      - zelphirkalt 5y ago
        What other tasks are planned in your current sprint?
        Tommek 5y ago
        Then you are not a devolper but an assembly line worker.
megous 5y ago
This solves only `npm install` and not other ways the package can be compromised. And you're still giving it plenty of access to any projects under your home dir, or opportunities to modify other npm packages that are being installed, to gain execution outside of sandbox later on.
pabs3 5y ago
Something like bubblewrap (which uses Linux namespaces) or firejail would be a simpler way to do a sandbox.
dathinab 5y ago
That is neither simple nor does it prevent some of the most common npm supply chain attacks (I think, no export with appamore). The most common attacks is to mess with thinks you build for release in ways which then allow attacking the consumer. For example by tweaking package, package lock, or even the source code. Only the last one is prevented here. Then there is also the thing that installing (user wide or even global) system utilities with npm is a thing, and wouldn't work with your apparmore profile (all need their own profile) Similar locally running node programs are an attack vector and your profile allow modifying the `node_modules` of such programs even if they don't use npm... Also you need root rights for loading profiles which can make having a profile for each project a problem as the dev doesn't necessary has root rights. (E.g. in a company with company managed desktop systems this is the default.) Don't get me wrong. I'm not saying you shouldn't use apparmore and other sandboxes. I even think it's the future of Linux. My point is appamore isn't simple and it's one of the most simple solutions out there. Or in other words we still have quite a way to go. And it's not just about doing sand-boxing, but also about managing sandboxed programs, e.g. last time I looked the app stores of both snap and flatpack where a horror-house of not-properly maintained packages with security vulnerabilities, as well as doggy potentially malicious "unofficial" packages. Even if you sandbox is perfect you still care about security, e.g. you don't want a openoffic package to send copies of all documents you use somewhere else... and that's if the sandbox if used (... flatpack ... facepalm).
- dathinab 5y ago
  > I even think it's the future of Linux. Let me correct it: It MUST be the future of Linux or Linux will have serious problems.

kelnos 5y ago

I think you have a definition of "easily" that many might not subscribe to. If this policy isn't available and enabled by default in some package containing common policies, do you really expect your average developer to a) even know anything about AppArmor, or b) know how to write an AppArmor policy file without spending a few hours digging through docs, reading examples, and engaging in a bunch of trial and error? (If your answer is "yes" to either of those questions, I'd suggest you might overestimate what is common knowledge.)

notpublic 5y ago
Fair enough. I meant easy as in without installing any additional software, minimal config and ease of use. AppArmor has come a long way. It's worth learning about it. They have quite a few builtin profiles that you can take advantage of.
BoorishBears 5y ago
Only on HN can you use the word "easy" to describe a set of steps that follow directly after, and still end up having to clarify the word easy referred to your steps, not to the entire concept of the underlying technology.
- dathinab 5y ago
  People mean the steps are not easy. Because it's now about copying them but being able to create them yourself on the fly for whatever you need.
  - BoorishBears 5y ago
    I really don't get what this is trying to say. Like, the tone of the comment makes no sense, the hard part isn't on the OP, and OP wasn't saying AppArmor is easy, just the content of their comment is easy (which it is!) It's like saying flipping a light switch to turn on a light is easy... the having someone fly in complaining that understanding industrial power generation is not easy at all.
    - varajelle 5y ago
      it's easy, just do 'rm rf /' My point is: how do we know the instructions are actually safe?
      - BoorishBears 5y ago
        Oh brother. It's like wrestling a pig in the mud. If you don't trust it, don't run it... but I don't know how anyone in software development would be unable to function if they've never been able to trust someone else's config file suggestion.
    - dathinab 5y ago
      > content of their comment is easy (which it is!) It's not, it has subtle gaps in the sandbox which still allow some of the attacks it's supposedly protecting you from.
Tommek 5y ago
We reached a state where code monkeys believe they are developers. Of course you should know about the machine you are developing on.
- theteapot 5y ago
  Nah. I agree with the other guy. AppArmour takes some time to learn and isn't super mainstream yet. At least it's a step forward from SELinux, but it still feels uncooked and adhoc to me.
- vlovich123 5y ago
  There's an insane amount of tooling with varying degrees of overlap. You've got SELinux, BPF, seccomp, AppArmor as different approaches to security. Each of these takes quite a bit of dedicated time to master and most of them have lots of nuance & there can be overlap depending on what you're trying to secure. In a work environment, I'd typically outsource this to security engineers/experts OR spend my time learning those things for what I need them for - knowing the tools are out there are sufficient starting points for research when I need that knowledge. None of this applies to maintaining my development machine. You might want to revisit your gate keeping.
  - fartcannon 5y ago
    Im not a developer, but in the field I work in, a couple hours dedicated to learning a tool that would help you isnt much of an ask. And the little demo script GP wrote seems pretty straight forward to me.
    - zelphirkalt 5y ago
      What other tasks are planned in your current sprint?
      - Tommek 5y ago
        Then you are not a devolper but an assembly line worker.

megous 5y ago

This solves only `npm install` and not other ways the package can be compromised. And you're still giving it plenty of access to any projects under your home dir, or opportunities to modify other npm packages that are being installed, to gain execution outside of sandbox later on.

pabs3 5y ago

Something like bubblewrap (which uses Linux namespaces) or firejail would be a simpler way to do a sandbox.

dathinab 5y ago

That is neither simple nor does it prevent some of the most common npm supply chain attacks (I think, no export with appamore). The most common attacks is to mess with thinks you build for release in ways which then allow attacking the consumer. For example by tweaking package, package lock, or even the source code. Only the last one is prevented here. Then there is also the thing that installing (user wide or even global) system utilities with npm is a thing, and wouldn't work with your apparmore profile (all need their own profile) Similar locally running node programs are an attack vector and your profile allow modifying the `node_modules` of such programs even if they don't use npm... Also you need root rights for loading profiles which can make having a profile for each project a problem as the dev doesn't necessary has root rights. (E.g. in a company with company managed desktop systems this is the default.) Don't get me wrong. I'm not saying you shouldn't use apparmore and other sandboxes. I even think it's the future of Linux. My point is appamore isn't simple and it's one of the most simple solutions out there. Or in other words we still have quite a way to go. And it's not just about doing sand-boxing, but also about managing sandboxed programs, e.g. last time I looked the app stores of both snap and flatpack where a horror-house of not-properly maintained packages with security vulnerabilities, as well as doggy potentially malicious "unofficial" packages. Even if you sandbox is perfect you still care about security, e.g. you don't want a openoffic package to send copies of all documents you use somewhere else... and that's if the sandbox if used (... flatpack ... facepalm).

dathinab 5y ago
> I even think it's the future of Linux. Let me correct it: It MUST be the future of Linux or Linux will have serious problems.