Live data from Hacker News

Alpine Linux Docker images have NULL for root password

cve.mitre.org

91–100 of 203 posts

Re: Alpine Linux Docker images have NULL for root password

#93
post #88

Earlier quoted context omitted.

Yeah, official alpine one looks fine $ docker run -it alpine head -1 /etc/shadow root:!::0:::::

Going through alpine:3.1 to alpine:3.9, then alpine:edge, I see that the following versions have the problem: 3.3, 3.4, 3.5, and 3.8.

3.8 looks fine?

  » docker run --rm -ti alpine:3.8 sh -c 'cat /etc/shadow | grep root'
  root:!::0:::::
The others you mention though, I agree, they look less than fine.

Also, has anyone reported this to the official Alpine repository? (since the Talos disclosure seems to be confused; it says official but has URLs to the Glider Labs version?)

Edit: Ah, so here's the relevant GitHub issue for official Alpine Linux docker: https://github.com/docker-library/official-images/pull/5516

<=3.5 is no longer supported. Everything newer is patched.

Re: Alpine Linux Docker images have NULL for root password

#95
post #58

Earlier quoted context omitted.

Because it's tiny, I tend to default to Alpine and then move away from it where necessary. Rather than worrying about potential CPU performance requirements upfront - premature optimisation and all that.

Isn't there an argument that using Alpine instead of something like Ubuntu is premature optimization for space?

It's faster in terms of development time. Faster to install packages and to push to docker repos.

Re: Alpine Linux Docker images have NULL for root password

#96
post #67

Earlier quoted context omitted.

Unless you're behind a load balancer which terminates TLS and the traffic you deal with is purely http.

Please don't do this anymore. End-to-end encryption is extremely easy to set up and maintain. P2PE will absolutely lull you into a false sense of security.

Everyone seems to think E2E encryption is needed everywhere (I know because the security guys at work think it is needed everywhere, even for everything inside a VPC), but even AWS here is advertising the fact that you don't need to do this:

https://aws.amazon.com/blogs/aws/new-tls-termination-for-net...

>Today we are simplifying the process of building secure web applications by giving you the ability to make use of TLS (Transport Layer Security) connections that terminate at a Network Load Balancer (you can think of TLS as providing the “S” in HTTPS). This will free your backend servers from the compute-intensive work of encrypting and decrypting all of your traffic, while also giving you a host of other features and benefits:

Re: Alpine Linux Docker images have NULL for root password

#97

I have always been a bit surprised at the popularity of Alpine Linux for docker images. It’s awesome that the images are pretty small, but a wide variety of software has been shown to run noticeably slower on Alpine compared to other distributions, in part due to its usage of musl instead of glibc. I’d think that a few megabytes of disk isn’t as valuable as the extra cpu cycles.

I've no idea why you wouldn't use Ubuntu which is only around 40mb, has a sane package manager and a standard glibc.

Ubuntu is 40MB but if you add a few packages with tons of dependencies it can quickly reach 800MB. Alpine has much more reasonable dependency trees.

Re: Alpine Linux Docker images have NULL for root password

#98

Earlier quoted context omitted.

Adding a shell seems antithetical to deploying production code as a static-linked binary, not to mention an expansion of the attack surface of the container.

Without a shell, how does one debug if anything goes wrong?

Reading logs/traces on your log aggregation service and reproducing in a dev system?

Re: Alpine Linux Docker images have NULL for root password

#99
post #36

Earlier quoted context omitted.

You're only playing that 40mb once though. Multiple containers sharing the same parent layers will not require additional storage for the core OS layer.

Are you guys running everything on a single box? Do you get all developers to agree on which base image to build all their services from? I heard about this "oh, it's shared, don't worry" thing before. It started with 40MB. Now that supposedly shared image is half a gig. "Don't worry, it's shared anyway". Expect when it isn't. And when it is, it still slow us down in bringing up new nodes. And guess what, turns out t…

> single box

In production, the smallest box has half a gig of RAM.

In development, it's indeed a single box, usually a laptop.

> all developers to agree on which base image to build all their services from

Yes. In a small org it's easy. In a large org devops people will quickly explain the benefits of standardizing on one, at most two, base images. Special services that are run from a third-party image is a different beast.

> Storage is cheap, but bandwidth may not be.

Verily! Bandwidth, build time, etc.

Post reply on HN