<colemickens>
If I'm understanding that right... :/
jasongrossman has joined #nixos-chat
__monty__ has joined #nixos-chat
__Sander__ has joined #nixos-chat
obadz has quit [Quit: WeeChat 2.3]
obadz has joined #nixos-chat
jasongrossman has quit [Ping timeout: 246 seconds]
jasongrossman has joined #nixos-chat
<kgz>
colemickens: but hopefully no one uses docker as a security measure
<tilpner>
But plenty of people are installing random binaries from ~~the internet~~ Docker Hub
<tilpner>
But grahamc is "pretty sure NixOS is not vulnerable" (check #nixos-security logs)
<srhb>
NixOS shouldn't be, but yeah. Opened a PR anyway.
<srhb>
This is not the first time it happens, and it won't be the last. I sure hope people don't allow root in their containers (but I know they do...)
<joepie91>
[11:15] <kgz> colemickens: but hopefully no one uses docker as a security measure
<joepie91>
a lot of people do
<joepie91>
the belief that Docker provides secure isolation is really widespread unfortunately
<srhb>
"secure" is a scale..
<srhb>
Until it isn't :-)
<joepie91>
"secure" in the sense of "secure against malicious users/programs as root"
<joepie91>
(which Docker isn't designed to be)
<srhb>
Not sure their marketing department would agree. :-P
<gchristensen>
what shykes said in a singel citeable HackerNews comment 4years ago does not reflect what their marketing department would say
<gchristensen>
you know it, he knows it, we know it, consumers of docker marketing probably don't
<lejonet>
What, you mean that containersation isn't a security boundry? :O I thought it was just lightweight VMs! </sarcasm>
<lejonet>
(I still don't understand what part of "Root in container is root on host" that people don't understand... root in the container has the same rights to modify the kernel usually... (unless userns, then its a little bit less but not much)
<joepie91>
gchristensen: aye, I just don't assign any value to marketing drivel
<joepie91>
:p
<joepie91>
lejonet: that is not true for OpenVZ though
<lejonet>
srhb: secure is a weighted scale, against a threat model... so I can design 150% secure system, as long as my threat model is bad enough xD
<lejonet>
joepie91: OpenVZ is a different beast than docker, rkt and LXC for example :)
<joepie91>
aye, but it's containers nevertheless
<joepie91>
you *can* design containers that can run untrusted code as root safely
<joepie91>
(for a reasonable value of 'safely')
<srhb>
I think we're all in violent agreement here.
<lejonet>
As they've actually gone in and done more work in the kernel to ensure separation and so (I'm not that familiar with OpenVZs details so don't qoute me on that)
<joepie91>
lejonet: yeah, basically they've heavily modified the kernel to fence off ~everything that could be abused
<lejonet>
joepie91: ofc, its all about what and how you separate :)
<lejonet>
srhb: Mhm, that is my analysis too
<lejonet>
joepie91: it could be argued, if you're allowed to abuse some terminology, that OpenVZ is a "true container" whereas docker, rkt and LXC is just "glorified, namespaced chroots"
<joepie91>
aye
<joepie91>
well
<joepie91>
supposedly unprivileged LXC can be equivalent to OpenVZ?
<lejonet>
Its still mainly based on namespacing, it still wouldn't have the hardening in kernelspace that OpenVZ has, but yeah, its not THAT far away
<lejonet>
namespacing + capabilities gets you fairly far honestly
<lejonet>
One of the biggest problem with root in containers is the fact that the uid 0 has some special handling in kernelspace, regardless of stuff enforced in userspace
<lejonet>
In some cases, its treat differently than "just" a uid
<__monty__>
Are rkt and openVZ vulnerable to the CVE? Sounds like openVZ isn't?
<lejonet>
(at least that is what I've been told, I haven't investigated what and where it'd be)
<__monty__>
I wonder why nspawn isn't though.
<joepie91>
__monty__: OpenVZ doesn't use runc
<joepie91>
nor even mainline kerneel
<joepie91>
kernel*
<joepie91>
at least, OpenVZ <7 didn't
<joepie91>
dunno about 7
<lejonet>
__monty__: allegedly nspawn isn't vulnerable due to them handling the namespacing differently
<lejonet>
But I haven't investigated the CVE all that thoroughly outside of the mail sent to openwall
<joepie91>
OpenVZ basically has (had?) its entire own customized kernel specifically for OpenVZ, based off 2.6
<joepie91>
with its own containerization implementation
<joepie91>
far predates the cgroups stuff etc. in Linux :P
<elvishjerricco>
Serious question: Containers are *supposed* to be secure though, even with uid = 0, aren't they? Any vulnerability is a bug? I.E. the problem is the shear size of the attack surface area, not the container model?
<tilpner>
Depends on which definition of container you use. If you ask kata containers, they'd probably say yes
<tilpner>
(But then, some people wouldn't call them containers)
<elvishjerricco>
Yea for instance systemd-nspawn still explicitly says it should not be considered secure IIRC
<__monty__>
Funny how it turns out to be toward the more secure end of the spectrum, at least for the moment : )
<joepie91>
elvishjerricco: I'd say that the base purpose of containers is protection against accidental(!) environment contamination
<joepie91>
not intentional contamination (ie. breakouts)
<elvishjerricco>
How does systemd determine when a unit has successfully "activated"? I've got one stuck in an `activating (start)` state.
<joepie91>
elvishjerricco: this is dependent on how the unit is defined, I believe; eg. a unit can be configured to wait for an active completion signal from the application
<elvishjerricco>
joepie91: Oh wait, does `BusName=...` imply `Type=dbus`? I guess that'd make sense, since there's no type line in this unit file.
<elvishjerricco>
In that case... I guess the daemon is failing to acquire the bus name
<joepie91>
elvishjerricco: hm, I'm not aware of systemd doing implicit anything. but possibly
<joepie91>
aha
<joepie91>
Behavior of dbus is similar to simple; however, it is expected that the service acquires a name on the D-Bus bus, as configured by BusName=. systemd will proceed with starting follow-up units after the D-Bus bus name has been acquired. Service units with this option configured implicitly gain dependencies on the dbus.socket unit. This type is the default if BusName= is specified.
<joepie91>
so it DOES do things implicitly
<elvishjerricco>
Now to figure out why it's not getting the bus name...
<lejonet>
Take this with a grain of salt but I think the notion of containers supposed to be secure, from a breakout/security perspective, mainly comes from people that don't really know what techniques that at least LXC, runc and rkt uses to "make" the containers
<lejonet>
I think it stems from the confusion of containers being "like a VM, but lighter on system resources"
<lejonet>
Whereas in reality, it doesn't share much but the logical separation with VMs, everything else is different
<lejonet>
However, as has been pointed out, you _can_ use containers securely, but they aren't in and off themselves any more secure than having say a chroot that gets some namespacing done for it
<gchristensen>
todo: generate a report out of it :|
<averell>
it would be pretty sweet if that could someday be part of the build plan. Oh you made an irrelevant whitespace change? I don't need to rebuild 4000 packages.
<samueldr>
"adding the quiet option cut 18 seconds off the boot time [of some machines]"
<joepie91>
lejonet: sounds about right
<samueldr>
(server hardware; power 9 mainly)
<gchristensen>
hilarious
etu has quit [Ping timeout: 250 seconds]
etu has joined #nixos-chat
__Sander__ has quit [Quit: Konversation terminated!]
<lejonet>
samueldr: I cut down kernel compile time with like 40 min by switching console on a server I have xD (it has a pre-KMS enabled AST chip for VGA...)
obadz has quit [Ping timeout: 272 seconds]
obadz has joined #nixos-chat
srhb- has joined #nixos-chat
{^_^} has quit [Ping timeout: 240 seconds]
drakonis has quit [Ping timeout: 240 seconds]
ma27 has quit [Ping timeout: 240 seconds]
sphalerite has quit [Ping timeout: 240 seconds]
lopsided98 has quit [Remote host closed the connection]
srhb has quit [Read error: Connection reset by peer]
andi- has quit [Ping timeout: 240 seconds]
srhb- is now known as srhb
{^_^} has joined #nixos-chat
ma27 has joined #nixos-chat
lopsided98 has joined #nixos-chat
drakonis has joined #nixos-chat
sphalerite has joined #nixos-chat
andi- has joined #nixos-chat
kgz has quit [Ping timeout: 250 seconds]
kgz has joined #nixos-chat
hedning has quit [Remote host closed the connection]
__monty__ has quit [Read error: Connection reset by peer]
__monty__ has joined #nixos-chat
__monty__ has quit [Remote host closed the connection]
__monty__ has joined #nixos-chat
lopsided98 has quit [Remote host closed the connection]
<elvishjerricco>
gchristensen: I was playing around with using systemd for initrd, since I really don't like the ad-hoc crappy device/filesystem dependency management we have now. Eventually got fed up trying to basically build an OS from scratch and just put NixOS in an initrd :P
<gchristensen>
nice :P
<elvishjerricco>
If I can get it small enough and disable enough services, there's a slim chance this could be usable
<elvishjerricco>
I was surprised to find it worked on the first try, whereas my other attempt took a while to get anywhere
<samueldr>
stupidest or wisest?
<samueldr>
I mean, you have a system to build a linux-based operating system *right there*
sphalerite_ is now known as sphalerite
<elvishjerricco>
samueldr: The reason I even started down this path is even stupider: Linux as the bootloader so that encrypted /boot doesn't take ages to unlock and for support for arbitrary file systems
<samueldr>
:)
<sphalerite>
oh but then you'll also need a smaller linux for your firmware ;)
<samueldr>
that's not stupid; I think mobile-nixos will need to act that way to work on the current targeted platforms
<sphalerite>
clever: I know how to configure and build a kernel, just not which options (are safe) to twiddle
<clever>
sphalerite: its mostly a guessing game
<sphalerite>
also I usually use with import <nixpkgs> {}; linux_latest.overrideAttrs (o: {src = null; nativeBuildInputs = o.nativeBuildInputs ++ [pkgconfig ncurses bison flex]; })
<samueldr>
yes, though I'm thinking that having the mobile nixos thing there makes sense if I need to deal with generations in the initrd anyways for phones
<samueldr>
(also thinking to make a standard UEFI mobile-nixos initrd to dogfood it)
<clever>
sphalerite: oh, lol, this kernel doesnt have module support enabled!
<samueldr>
probably not an issue if the goal is to kexec into a bigger badder kernel
<sphalerite>
clever: yeah, I strongly suspect that a config pieced together like that won't boot on here
<sphalerite>
clever: not because it doesn't have module support but because it doesn't have the hardware support
<clever>
sphalerite: it would help if i had a .config to start with, oh, the one you linked may help
<sphalerite>
:p
<elvishjerricco>
I can't even find the part of NixOS that deals with `systemd.packages`...