Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maybe you shouldn't install new software for a bit

xeiaso.net

Post reply on HN
Print view View original

441–450 of 497 posts

Re: Maybe you shouldn't install new software for a bit

#441

Post by Animats »

marcus_holmes wrote: post #57

This was always a nightmare waiting to happen. The sheer mass of packages and the consequent vast attack surface for supply chain attacks was always a problem that was eventually going to blow up in everyone's face. But it was too convenient. Anyone warning about it or trying to limit the damage was shouted down by people who had no experience of any other way of doing things. "import antigravity" is just too easy to…

> The sheer mass of packages

Yes.

I just noticed that a Rust program I'm working on had acquired a plotter driver crate. A plotter driver? The program has no graphical output.

Turns out that "kdtree" has a dev dependency on a profiling library that pulls in a whole graphics system. Even in release mode, I get that, because I have debug symbols turned on, which activated dev dependencies.

Aargh.

Re: Maybe you shouldn't install new software for a bit

#442

Post by endospore »

Animats wrote: post #441
marcus_holmes wrote: post #57

This was always a nightmare waiting to happen. The sheer mass of packages and the consequent vast attack surface for supply chain attacks was always a problem that was eventually going to blow up in everyone's face. But it was too convenient. Anyone warning about it or trying to limit the damage was shouted down by people who had no experience of any other way of doing things. "import antigravity" is just too easy to…

> The sheer mass of packages Yes. I just noticed that a Rust program I'm working on had acquired a plotter driver crate. A plotter driver? The program has no graphical output. Turns out that "kdtree" has a dev dependency on a profiling library that pulls in a whole graphics system. Even in release mode, I get that, because I have debug symbols turned on, which activated dev dependencies. Aargh.

> I have debug symbols turned on, which activated dev dependencies

Nope that doesn't happen. It's not compiled into your binary if it's a dev or build dependency. Cargo may have downloaded the crate source according to the lockfile and that's it, it shouldn't build anything unneeded.

Re: Maybe you shouldn't install new software for a bit

#444

Post by Animats »

endospore wrote: post #442
Animats wrote: post #441

Earlier quoted context omitted.

> The sheer mass of packages Yes. I just noticed that a Rust program I'm working on had acquired a plotter driver crate. A plotter driver? The program has no graphical output. Turns out that "kdtree" has a dev dependency on a profiling library that pulls in a whole graphics system. Even in release mode, I get that, because I have debug symbols turned on, which activated dev dependencies. Aargh.

> I have debug symbols turned on, which activated dev dependencies Nope that doesn't happen. It's not compiled into your binary if it's a dev or build dependency. Cargo may have downloaded the crate source according to the lockfile and that's it, it shouldn't build anything unneeded.

OK, I have to check the binary.

Re: Maybe you shouldn't install new software for a bit

#445

Post by brewmarche »

Melatonic wrote: post #438
brewmarche wrote: post #389

Earlier quoted context omitted.

My experiences from dabbling with it a few months ago: In general everything needs to be compiled for FreeBSD, but the ports collection is quite extensive. For example you will find Firefox, wayland, GNOME, KDE, xfce, … even dotnet was on there. Problems arise with properietary stuff like Spotify, Widevine DRM etc. However, FreeBSD has a Linux emulation layer (providing syscalls), dubbed ‘Linuxulator’. I managed to r…

I could be wrong but I think Jails are separate from containers on BSD?

I thought that podman uses jails under the hood on FreeBSD, but it is a guess. The podman code seems to reference jails: https://github.com/search?q=repo%3Acontainers%2Fpodman%20fre...>

But jails of course are older and can be used on their own, I didn’t want to imply they’re the same thing

Re: Maybe you shouldn't install new software for a bit

#447

Post by josephg »

mike_hearn wrote: post #360
josephg wrote: post #341

Earlier quoted context omitted.

> I wrote an essay explaining the issues here This essay only addresses my second point - capabilities within a program. It doesn't address OS level capabilities at all. But even in the space of programming languages, I find this essay extremely unconvincing. Like, you raise points like this: > Here are some problems you’ll have to solve in order to sandbox libraries: What is your threat model? How do you stop compon…

The article talks about OS capabilities in the second part when it discusses Mojo, which is based on IPC. > The solution is to design a language such that if I import leftpad, then call it, my computer can't get hacked. That requirement may seem clear right now, but the moment you talk to other people about your language you'll find there's no agreement on what "get hacked" means. Some people will consider calling ex…

> We're talking about critical bugs in the filesystem so what the FS processes idea of a file handle is doesn't really matter.

The copyfail bug wasn’t a bug in the filesystem code. It was a bug in the crypto algorithm code, which wrote to the filesystem page table without checking if the process invoking it had permission to write to the passed file handle. In a monolithic kernel like Linux, every subsystem can access the memory of every other subsystem by default. It’s up to each subsystem to be careful. As we keep discovering, “be really careful” is not a successful security strategy.

A capability based OS like SeL4 is more secure. With SeL4, you would put the crypto algorithms and filesystem in separate user space processes. These processes would only communicate by RPC, by invoking capabilities. We can imagine how the copyfail scenario would play out: A user process has a capability representing its (read only) access to some privileged file on disk. It passes that capability to the crypto algorithm process. A bug - or even complete takeover - of the crypto algorithm process still doesn’t change that the file cap is read only. The crypto algorithm process doesn’t have direct access to the memory representing that file. It only has the read only file handle. All it can do with that handle is invoke it, which will only give it read access. Even with a bug in the crypto algorithms process, the OS would stay secure.

Yes, capability OSes aren't a magic bullet. A bug in the filesystem process could still result in filesystem corruption. But better is better. OS capabilities provide defence in depth. They would have prevented copyfail.

As far as I can tell, your argument against capabilities is that they might be slow. Some implementations have poor ergonomics. They don’t magically solve every possible security bug. You also, personally, used a bad implementation of capabilities this one time years ago in Java. Is that accurate?

You must see how unconvincing I find your argument. What are you even trying to do? Convince people to not explore different ideas in computer science? When I close my eyes I see an old man yelling: “Hey you kids! What are you doing up there, trying new things? You stop that right now!”

Re: Maybe you shouldn't install new software for a bit

#448

Post by ric2b »

pjmlp wrote: post #216
AgentME wrote: post #16

There's already an okay solution to supply-chain attacks against dependency managers like npm, PyPI, and Cargo: set them to only install package versions that are more than a few days old. The recent high-profile attacks were all caught and rolled back within a day, so doing this would have let you safely avoid the attacks. It really should be the default behavior. Let self-selected beta testers and security scanner…

Even better, only use company vetted repos, everyone is forbidded to install directly from the Internet repos. This naturally doesn't work outside corporations.

That usually ends up as proxies to the upstream repos, because the people managing the company repos don't have time to review every new version of a package.

At that point you're just as vulnerable to a supply chain attack.

Re: Maybe you shouldn't install new software for a bit

#449

Post by Izkata »

skydhash wrote: post #286
rounce wrote: post #273

Earlier quoted context omitted.

This is related to a massive annoyance of mine: when I run a piece of software and the system is missing a required dependency, I want the software to *tell me* that dependency is missing so I can make a decision about proceeding or not. Instead it seems that far too often software authors will try and be “clever” by silently installing a bunch of dependencies, either in some directory path specific to the software,…

Ruby gems and CPAN have build scripts that rebuild stuff on the user's device (and warn you if they can't find a dependency). But I believe one of the Python's tools that started the trend of downloading binaries instead of building them. Or was it NPM?

Python's pip predates npm, installs dependencies automatically, can include binaries, and the old-style packages could run arbitrary code during the install.

Ruby gems are older than that, but I have no idea what capabilities it has/had.

Post reply on HN