News for hackers. Stuff that matters.
Re:Can we get the benefits of transitive dependencies withou... by est31 on Tuesday January 28, 2025 @05:13PM (#42858771)
Re:Can we get the benefits of transitive dependencies withou... by IshKebab on Tuesday January 28, 2025 @05:23PM (#42858902)
Deno controls access at the process level, so it's better than nothing but it doesn't really help with this specific problem. Also it delegates setting the permissions up to the user, and we know that in practice everyone is just going to --allow-all.
Re:Can we get the benefits of transitive dependencies withou... by kybernetikos on Wednesday January 29, 2025 @02:41AM (#42862558)
The key requirement to solve this problem is that you can ensure that third party libraries get a subset of the permissions that the code calling them has. E.g. My photo editor might need read and write access to my photo folder, but the 3rd party code that parses jpegs to get their tags needs only read access and shouldn't have the ability to encrypt my photos and make ransom demands.

Deno took a step in a good direction, but it was an opportunity to go much further and meaningfully address the problem, so I was a bit disappointed that it just controlled restrictions at the process level.

Re:Can we get the benefits of transitive dependencies withou... by nonameiguess on Wednesday January 29, 2025 @11:54AM (#42867597)
Kind of two different things being addressed here. The article is talking about doing this at the granularity of preventing imported library code from having the same capabilities as the caller, which requires support from the language runtime, but the comment being responded to was saying there is no way in 2025 to run a program and keep it from accessing the network or the filesystem.

That is simply not true. There are many ways to do that, which have been answered already. SELinux. Seccommp profiles. AppArmor. Linux containers (whether that be OCI, bubblewrap, snap, app images, or systemd-run). Pledge and jails.

These are different concerns. One is software developers wanting to code into their programs upper limits to what imported dependencies can do. That is poorly supported and mostly not possible outside of research systems. The other is end users and system administrators setting limits on what resources running processes can access and what system calls they can make. That is widely supported with hundreds of ways to do it and the main reasons it is perceived as complicated is because software usually assumes it can do anything, doesn't tell you what it needs, and trying to figure it out as an end user is an endless game of playing whack-a-mole with broken installs.