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

Codex just found a "workaround" of not having sudo on my PC

twitter.com

Post reply on HN
Print view View original

151–160 of 330 posts

Re: Codex just found a "workaround" of not having sudo on my PC

#151

Post by godelski »

MrDrMcCoy wrote: post #122
godelski wrote: post #102

Earlier quoted context omitted.

> In what way is it a replacement for docker? Look at the man pages for `machinectl` (then `systemd-nspawn`, `systemd-vmspawn`, and if you want `systemd-portabled`). This is a replacement for docker. These are container tools offered by systemd.

The problem is that the tooling for creating, importing, and managing images is not as good with systemd vs Podman/Docker. There's also no clear path to import images from the Docker ecosystem, at least as far as user experience goes. I know how to do it, but the number of extra steps involved always drives me back to Podman.

I don't really find them that bad but I'm still going to maintain my "different strokes for different folks" position. Might be bad for you and good for others. More options isn't a bad thing

Re: Codex just found a "workaround" of not having sudo on my PC

#152

Post by godelski »

ciupicri wrote: post #121
godelski wrote: post #102

Earlier quoted context omitted.

> In what way is it a replacement for docker? Look at the man pages for `machinectl` (then `systemd-nspawn`, `systemd-vmspawn`, and if you want `systemd-portabled`). This is a replacement for docker. These are container tools offered by systemd.

podman is supposedly a replacement for docker.

There's plenty of container technologies and I'd be happy to see more of them used. Podman isn't for me, but it is a great option for others. Regardless, I think it is relatively unknown that systemd can be used for creating containers.

Re: Codex just found a "workaround" of not having sudo on my PC

#154

Post by twelvedogs »

amelius wrote: post #127
Ajedi32 wrote: post #95

Earlier quoted context omitted.

That's why adding your user account to the docker group is a separate step that explicitly does not happen as part of the installation: https://docs.docker.com/engine/install/linux-postinstall/ > Warning > The docker group grants root-level privileges to the user. For details on how this impacts security in your system, see Docker Daemon Attack Surface.

And containers were supposed to make things safer ... Huge design mistake if you ask me.

i don't see how it's a design mistake, linux allows more footguns in general to not decrease utility. Allowing you to manually give root prompt access (with warnings!) to a non-root user is one of them.

you can also just not run docker as root and not add normal users to the docker group

Re: Codex just found a "workaround" of not having sudo on my PC

#155

Post by fragmede »

SubiculumCode wrote: post #87

So in Linux, every process I start has my group permissions? I guess I knew that...but I have to say, have we reached a point where the Linux security model is just way to broad?

This was noted in 2013, at least. https://xkcd.com/1200/

Re: Codex just found a "workaround" of not having sudo on my PC

#156

Post by SpaceNoodled »

HeWhoLurksLate wrote: post #140
Ajedi32 wrote: post #95

Earlier quoted context omitted.

That's why adding your user account to the docker group is a separate step that explicitly does not happen as part of the installation: https://docs.docker.com/engine/install/linux-postinstall/ > Warning > The docker group grants root-level privileges to the user. For details on how this impacts security in your system, see Docker Daemon Attack Surface.

wait so just being lazy and using sudo on Docker commands instead of figuring things out actually means I'm being safer? awesome.

This feels like using Docker is just inherently unsafe.

Re: Codex just found a "workaround" of not having sudo on my PC

#158

Post by furyofantares »

SonOfLilit wrote: post #70
CSMastermind wrote: post #42

I realize this is supposed to be a post about how scary the security vulnerabilities these agents will find are. But personally I love when agents do things like this and appreciate the help. Last thing in the world I want is for them to nerf the models.

It's not about hacking capabilities, it's about misalignment. More like the golem myth (told it to fetch some water, drowned a city) then the gollum myth (used ring, ring hacked his brain, now he's a crazy violent meth addict).

I'm not sure I'd call it an alignment issue, because, in all cases I've seen where it does this (usually what I've seen is writing a python script to get around the harness permissions blocking something), it's trying to do the thing I just told it directly to do, and it's overcoming obstacles to accomplishing that.

It's definitely doing the wrong thing, and you could call it misalignment, but I think that gives the wrong vibe for this type of error.

Re: Codex just found a "workaround" of not having sudo on my PC

#159

Post by H4lcyon »

alephnerd wrote: post #9
dangus wrote: post #3

Earlier quoted context omitted.

Right, why is their login user in the docker group? Mine sure isn’t.

Becuase a lot of devs don't know this stuff. There's a reason security engineers (as in SWEs who specialize in securing specific attack surfaces) remain in hot demand.

Security engineer here :) Just a little side note, docker is also very often useful for evading EDR/XDR/etc. Want to talk to a domain controller with something like impacket but your EDR kills it? Try a container.

Re: Codex just found a "workaround" of not having sudo on my PC

#160

Post by eddythompson80 »

fps-hero wrote: post #124
eddythompson80 wrote: post #22

Earlier quoted context omitted.

I don't really know of any distro that doesn't do that. All of Docker Inc. default installs and all of distros I know of don't automatically add you to the docker group. docker.com instructions has the infamous "linux post-install instructions" that explain and walk you though it. The tragedy is of course that when security and usability collide, 80/20 rule will apply where 80% of people will pick usability over secu…

That’s the mental model that works for people, specifically those that come from VM workflow. Ironically that’s how Docker works on every platform where it’s running a non-native OS. On macOS that’s how all images are run. Linux on Linux is the only Docker combination that is particularly problematic from a security perspective. Virtualisation has advanced greatly since docker was introduced, if your running in local…

I agree that virtualization has seen great advances. Kata containers on k8s are almost (not quite 100%) drop in replacement. Regardless those last 10% remain a problem.

I run a personal server for few open source applications for personal use. I was thinking with all the supply chain attacks, and how carelessly I run `docker pull`s to update things I should probably consider hardening things a bit. I thought before jumping to full virtualization with Kata I can easily try gvisor/runsc first. Only to realize that DNS resolution is completely different with runsc vs runc and had to switch back.

Another sticking issue with virtualization is resource allocation. With namespace docker you can easily oversubscribe each container CPU/memory and rely on the single kernel letting individual containers burst as needed. With full virtualization this is still a big problem. Even with balloon devices and dynamic memory and CPU etc, the resource allocation is still not optimal. On a basic 8 core/16GB machine you can run 1 or 2 dozen services and things generally workout fine. Trying to run each of those in a virtualized VM you suddly can maybe run 6 or 7 maybe. There is no way to tell VM 3 kernel to drop its file system cache because VM 6 needs to load a large file in memory. Even if you script it out, now VM 3 is slow because it dropped all its cache while VM 6 finished processing 3 hours ago. These are not unsolvable problems, but despite how far virtualization has come, are still friction points.

Not to mention issues like sharing hardware devices (GPUs, disks, USB devices etc) between multiple VMs

Post reply on HN