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

The sad state of sysadmin in the age of containers

vitavonni.de

Post reply on HN
Print view View original

61–70 of 466 posts

Re: The sad state of sysadmin in the age of containers

#61

Post by rlpb »

rsanders wrote: post #60

I was doing sysadmin the "right way" a long, long time ago, and I don't see much difference. Maybe the author regularly does full audits of the source code of every package he downloads, and of course disassembles every executable and library in the underlying OS, but most of us don't. There's no wisdom or security to be gained from the act of running "make", much less "make install".

There's a huge difference.

> Maybe the author regularly does full audits of the source code of every package he downloads, and of course disassembles every executable and library in the underlying OS, but most of us don't.

What matters is that the source code is auditable. It only takes one person to investigate something suspicious, raise a flag and get it fixed.

This is certainly still true for Debian - not being able to build from source is considered a release blocking bug.

Re: The sad state of sysadmin in the age of containers

#62

Post by TheDong »

amouat wrote: post #49
TheDong wrote: post #38

Earlier quoted context omitted.

Not even close. Docker now has some terribly attempts at signing images on their registry iirc (docker inc signs them for the docker client). There is no option for me, as a user, to build and sign my own image with my own pgp key afaik. My organization might already have a chain of trust, and docker is asking me to ignore that and just trust their signatures (which also only work on dockerhub as of docker 1.5... don…

Docker didn't fuck up when they hired the square guys. http://blog.docker.com/2015/03/secured-at-docker-diogo-monic... I agree that security and provenance is a real issue in Docker. It is however being worked on, and it will be solved. Presumably we will end up with some sort of app-store like framework with proper signatures and verification. Docker can't do everything at once. Give them a chance. The new version o…

Cool, they hired some people, but I haven't noticed better security for it yet.

Security is a real issue in docker and it is being worked on, but I don't think "give them a chance" is a justifiable response. They're not focusing on it strongly. They already should have focussed on it and didn't. Their entire codebase was written without a security design in place, so there's likely deep-seated refactoring that'll need to be done before any new security-related features should be trusted.

They're working harder on monetizing and pushing docker as a production-ready standard as far as I can tell... I can understand not doing security before functionality, but it absolutely should be there before 1.0 or before you encourage others to use your software.

Docker has already lost any chance of me trusting their security with their lack of focus on it and I don't think it's excusable.

And if I'm doing what you say at the end, why the hell would I be using docker anyways then? I can already turn a tarballed fs into a linux container without docker (ty lxc); I thought the whole point of docker was sharing images and building on them and ... and having massive security flaws. Right.

Re: The sad state of sysadmin in the age of containers

#63

Post by Nursie »

rsanders wrote: post #60

I was doing sysadmin the "right way" a long, long time ago, and I don't see much difference. Maybe the author regularly does full audits of the source code of every package he downloads, and of course disassembles every executable and library in the underlying OS, but most of us don't. There's no wisdom or security to be gained from the act of running "make", much less "make install".

>> Maybe the author regularly does full audits of the source code of every package he downloads, and of course disassembles every executable and library in the underlying OS, but most of us don't.

This is not the point being made. Trust is often offloaded, say to the debian people, but it is present in most modern linux systems as a basic part of the setup.

>> There's no wisdom or security to be gained from the act of running "make", much less "make install".

'make' is brought up not because everyone should be running "make" or "make install", but because it's a standard and it is understood by many people. It's brought up in the context of hadoop because the hadoop build system appears to be just so complicated and non-standard, including pulling in untrusted sources from all over the place, that it is near impossible to set it up as a well-audited, standardised package.

Given this, it is likely to be a hive of vulnerabilities, either during the setup phase (if any of the third party servers gets compromised or MITM'd) or during deployment (that java VM it pulled in during setup is never going to get patched).

Re: The sad state of sysadmin in the age of containers

#64

Post by creshal »

hurin wrote: post #12
blfr wrote: post #4

This bothers me as well. Even tasks as simple as adding a repository are now being "improved" with a curl | sudo bash style setup[1]. However, installing from source with make was (and remains) a mess. It may work if you're dedicated to maintaining one application and (part of) its stack. But even then it usually leads to out of date software and tracking versions by hand. Many people have this weird aversion to doin…

> Many people have this weird aversion to doing basic sysadmin stuff with Linux. What makes it weird is that it's really simple. Often easier than figuring out another deploy system. While I agree with the articles main points - the GNU build system is far from simple. Basically an arcane syntax limited to unix-based systems and 5 or 6 100+ page manuals to cover. It doesn't excuse it - but I think it's easy to see wh…

> the GNU build system is far from simple

Which is why there's alternatives – cmake, waf, …

Re: The sad state of sysadmin in the age of containers

#65

Post by tribaal »

stephenr wrote: post #32
blfr wrote: post #4

This bothers me as well. Even tasks as simple as adding a repository are now being "improved" with a curl | sudo bash style setup[1]. However, installing from source with make was (and remains) a mess. It may work if you're dedicated to maintaining one application and (part of) its stack. But even then it usually leads to out of date software and tracking versions by hand. Many people have this weird aversion to doin…

I agree that the "just curl this into bash" instructions are nightmare - on any platform. I think a lot of this is a result of what I like to call the "Kumbaya approach to project/team management": This is where you have a team (either for a single project or a team at a consulting agency, etc) that is effectively all development-focused staff, possibly with some who dabble in Infrastructure/Ops. In this environment,…

> I think a lot of this is a result of what I like to call the "Kumbaya approach to project/team management"

I'm totally stealing this :)

Re: The sad state of sysadmin in the age of containers

#66

Post by rlpb »

TheDong wrote: post #45
lmm wrote: post #11

make is the least-auditable build tool imaginable. You don't have to obfuscate a Makefile, they come pre-obfuscated; you could put the "own me" commands right there in "plain" Make. Not to mention that it's often easier to tell whether a Java .class file is doing anything nefarious than whether a .c file is. How many sysadmins read the entire source of everything they install anyway? Maven, on the contrary, is the bi…

Signed packages isn't about just being signed. I could sign anything I like, but that doesn't make it any more secure for you to curl it into /bin/bash. Signatures are about who signs it, and that's not something mvn has solved at all. Mvn is a free-for-all of binary code that very well could own my system, wheras debian is a curated collection of software which the debian maintainers have signed as being compiled by…

> wheras debian is a curated collection of software which the debian maintainers have signed as being compiled by their systems with no malign influence and having met at least some bar.

And not only that, by shipping the source and requiring that binaries can be built from the source, who signs it is no longer blind trust. Others can audit it.

Reproducible builds should improve this even further.

Re: The sad state of sysadmin in the age of containers

#67

Post by pjmlp »

> »Docker is the new 'curl | sudo bash'«.

Fully agree with this.

Maybe I am just only another grey beard grumpy developer, but the new generations that grew up with GNU/Linux instead of UNIX, bash the security of other OSes and then go running such commands all the time.

Re: The sad state of sysadmin in the age of containers

#68

Post by yAnonymous »

stephenr wrote: post #32
blfr wrote: post #4

This bothers me as well. Even tasks as simple as adding a repository are now being "improved" with a curl | sudo bash style setup[1]. However, installing from source with make was (and remains) a mess. It may work if you're dedicated to maintaining one application and (part of) its stack. But even then it usually leads to out of date software and tracking versions by hand. Many people have this weird aversion to doin…

I agree that the "just curl this into bash" instructions are nightmare - on any platform. I think a lot of this is a result of what I like to call the "Kumbaya approach to project/team management": This is where you have a team (either for a single project or a team at a consulting agency, etc) that is effectively all development-focused staff, possibly with some who dabble in Infrastructure/Ops. In this environment,…

>[1] yes this is an exaggeration

No, it's not :(

Re: The sad state of sysadmin in the age of containers

#69

Post by ckozlowski »

empressplay wrote: post #57
peteretep wrote: post #15

Earlier quoted context omitted.

> As far as I know, it's also still standard practice in > most companies to either read the source code of open- > source stuff before deploying it to production (binary > or build) or get a support contract from someone else > who has I'm afraid I have no better, more cogent response for this than 'lol'.

This is an interesting read: http://www.bearingpoint.com/en-no/download/Open_Source_Gover...

Thanks for the share. =)

I'll queue this to read later, but just reading the executive statement, it seems to jive with a lot of the discussion here.

The issue isn't that code review /shouldn't/ be taking place, or even that there aren't directives stating that it should be done. It's that it isn't being done, and that's a problem.

Post reply on HN