<    March 2017    >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 24 25  
26 27 28 29 30 31
00:37 <TemptorSent> fabled / ncopa: What would be the difficulty of teaching apk to verify the signature on any file given a key and a file?
01:55 s33se joined
02:29 Emperor_Earth joined
04:53 <TemptorSent> RFC: Initfs init stub loader with integrity checks: http://termbin.com/eq512
04:54 <TemptorSent> It has me somewhat sidetracked from the rest of mkimage, but looking at the current situation, I think it's important we get the trust model to work better.
04:56 <TemptorSent> Static is not a necessity I suppose, but using dynamic libs will require keeping track of sums for a lot more files.
06:03 <TemptorSent> 'evening kaniini :)
06:20 alacerda_ joined
06:48 tmh1999 joined
07:37 tty` joined
07:38 fekepp joined
08:09 leo-unglaub joined
08:19 rrx joined
08:28 tty` joined
08:50 vakartel joined
08:57 <skarnet> TemptorSent: a few comments:
08:57 <skarnet> * #!/bin/sh -e for safety
08:58 <skarnet> * if this script runs as /init, you don't need to start with umounting everything. You *will* have a clean slate. If it's not the case, you have bigger problems.
08:59 <skarnet> * once again, you do not need to mount a tmpfs inside initramfs.
09:00 <skarnet> * you do not need to rm -rf /proc and /dev. If they're not empty, you have bigger problems (and mounting over them will still work anyway)
09:00 royger joined
09:01 <skarnet> * don't mknod inside /dev. Assume devtmpfs is mounted at boot time, or mount it. static dev is 1990s.
09:02 t0mmy joined
09:02 ncopa joined
09:02 fekepp joined
09:03 <skarnet> * you're calling $APK and $BB right after wiping out everything. That's not going to work. You need to call the copies in /.init.d.
09:04 <skarnet> More generally, I'm confused on what you're trying to achieve. If you want to make a new root even for the initramfs just to be sure, then you need to copy everything you need into it then switch_root.
09:05 <skarnet> If you just want to reach a state you control despite potential initramfs add-ons, you need to list exactly the files you want and erase the rest, and /.init.d is a distraction.
09:05 <skarnet> Mounts are also a distraction - you'll never start with anything more than /dev mounted.
09:13 jirutka joined
09:48 stwa joined
09:57 stwa joined
10:37 fekepp joined
10:45 vakartel joined
10:45 vakartel joined
11:18 <pickfire> Does alpine do https://wiki.archlinux.org/index.php/DeveloperWiki:Security#Replacing_setuid_with_capabilities
11:22 <skarnet> that's a very high hanging fruit
11:23 <pickfire> skarnet: huh?
11:23 <pickfire> I don't get what you mean.
11:24 <skarnet> Achieving this requires a lot of effort for a small-to-moderate benefit.
11:24 <skarnet> That's my opinion and does not necessarily reflect official Alpine policy.
11:25 <pickfire> skarnet: But doesn't getting minimal priveledges best for security?
11:25 <pickfire> I mean lower the risks.
11:26 <skarnet> of course, but I don't think capabilities is the right, or the easiest, way of minimizing privileges.
11:30 <pickfire> skarnet: how so?
11:31 <skarnet> Because it adds complexity and maintenance burden instead of reducing them, and proper uid usage is a much lower hanging fruit.
11:31 <skarnet> I've already ranted about this before.
11:31 <skarnet> And obviously, not everyone agrees.
11:34 <pickfire> skarnet: Wowo
11:34 <pickfire> suckless init is considered by many as the smallest possible init. I disagree: suckless init is incorrect, because it has no supervision capabilities, and thus, killing all processes but init can brick the machine. Nevertheless, suckless init, like many other suckless projects, is a neat exercise in minimalism.
11:34 <pickfire> http://www.skarnet.org/software/s6/
11:34 <pickfire> What? Is that you?
11:35 <skarnet> Yes.
11:35 <pickfire> skarnet: Why is suckless init bad?
11:36 <skarnet> You just quoted it.
11:36 <skarnet> If you kill -9 -1 on a machine running suckless init, you brick the machine and need a hard reboot.
11:36 <pickfire> Ah
11:37 <pickfire> skarnet: Including doing it as a user?
11:37 <skarnet> no, of course XD
11:37 <pickfire> Who does sudo kill -9 -1
11:38 <pickfire> skarnet: Do you use runit on alpine?
11:38 <skarnet> Who does fork bombs? Who writes programs that crash?
11:38 <pickfire> wAh
11:38 <skarnet> No, I use s6 on Alpine and everywhere else :P
11:38 <pickfire> Hehe
11:38 <pickfire> skarnet: How's it compared to openrc?
11:39 <pickfire> I can just replace openrc with runit right?
11:39 <minimalism> Got highlighted during an interesting conversation here..
11:39 <skarnet> minimalism: your fault for having such a nick ;)
11:39 <pickfire> minimalism: Hehe, thanks to skarnet quote
11:39 <minimalism> I never tried S6, but does that work out well for a distro like Alpine?
11:40 <skarnet> pickfire: no, openrc and runit do different things. The former is a service manager. The latter is a supervision suite.
11:40 <pickfire> minimalism: I think you should be in #suckless, are you in the wrong channel?
11:40 <minimalism> I've only heard some opinions and descriptions of it here and there
11:40 <pickfire> skarnet: I see no difference.
11:40 <skarnet> pickfire: watch my fosdem talk for an explanation of the difference :)
11:40 <pickfire> Where?
11:40 <skarnet> https://fosdem.org/2017/schedule/event/s6_supervision/
11:41 <skarnet> minimalism: s6 is distro-agnostic, so I'd say it works out well for everything, but I'm biased
11:42 <pickfire> skarnet: So you use runit together with openrc?
11:43 <skarnet> no, I use s6 together with s6-rc.
11:43 <pickfire> ?
11:43 <pickfire> Let me see your talk later. Mum calls.
12:05 rdutra joined
12:09 leitao joined
12:20 farosas joined
12:25 blueness joined
12:33 ferseiti joined
12:40 StarWarsFan|afk joined
13:06 gromero joined
13:24 atmoz joined
14:30 vakartel joined
14:32 stwa joined
14:59 tg joined
15:04 ferseiti joined
15:51 volleyper joined
15:56 <kaniini> pickfire: something like apparmor is more immediate. but yes, removing setuid is something we do want to do
15:58 <pickfire> Ah
15:58 fekepp joined
15:58 <pickfire> kaniini: Do you still keep track of s6 for alpine?
15:59 <skarnet> he keeps track of a lot of things :P
15:59 <pickfire> Aha
15:59 <pickfire> skarnet: You are here as well. :)
15:59 <pickfire> Must have highlighted you with the word "s6"
16:00 <asie> probably
16:00 <skarnet> look in your logs above, you already knew I was here
16:36 t0mmy joined
16:39 <^7heo> TemptorSent: but yeah TBB was right, wrong channel, it's here you wanna ask ;)
17:17 czart_ joined
17:30 Shiz joined
17:36 rdutra1 joined
17:48 fekepp joined
18:56 kunkku joined
19:43 blueness joined
20:21 rrx joined
20:24 BitL0G1c joined
20:44 blueness joined
20:57 blueness joined
21:04 <gromero> Hi. Does Alpine support reverse dependency search (to see which packages depend upon a given one)?
21:07 stwa joined
21:09 <kaniini> apk info --rdepends
21:15 <gromero> kaniini: thanks
21:32 <TemptorSent> Revised stub loader for comment: http://termbin.com/g396
21:35 <kaniini> i like it
21:36 <TemptorSent> kaniini: Does it address all the major issues for verification of our boot artifacts?
21:38 <kaniini> if we are using static apk and static busybox, yes
21:38 <TemptorSent> kaniini: That was the idea... we can install a 'normal' BB/apk once we're done with our early boot.
21:39 <TemptorSent> kaniini: Or retain the static versions, as desired.
21:40 <skarnet> keep #!/bin/sh and make a symlink sh->busybox
21:41 <TemptorSent> kaniini: Not the solution for ultra-thin, but we can do a custom shim for those
21:41 <TemptorSent> skarnet: Do we trust that symlink?
21:41 <TemptorSent> skarnet: I'm paranoid :)
21:42 <skarnet> why would we trust it less than anything else that's in the initramfs
21:42 <TemptorSent> skarnet: Hence the canary value I'm thinking to add.
21:42 <TemptorSent> skarnet: Because it coulde be altered in the cpio archive without having anythign to checksum
21:44 <skarnet> I don't understand, and I don't get the point of DIRTY either.
21:44 <TemptorSent> skarnet: If we get called from the kernel, call a specific binary, then proceed to verify both our own integrity, that of the interpeter, AND that of the validation tool, we have a pretty small window.
21:44 <skarnet> and I insist about set -e
21:44 <TemptorSent> skarnet: DIRTY is to be passed down through the process and set true or cleared before any non-verified code is called.
21:45 <TemptorSent> What is the behavior of -e in PID 1?
21:45 <TemptorSent> Do we hang?
21:45 <skarnet> kernel panic.
21:45 <skarnet> (the process just exits)
21:45 <TemptorSent> We'd much rather just reboot IMHO
21:46 <skarnet> then add || reboot at the end of every line, wheeee
21:46 <TemptorSent> skarnet: Yeah, or at least any which a failure would be a bad thing.
21:47 <skarnet> honestly, if you fail this early, a kernel panic isn't a problem, because chances are you won't get much further after a reboot
21:47 <TemptorSent> or use -e and use | true / || true everywhere it's not a fail and let it fall through.
21:47 <skarnet> you need admin intervention anyway.
21:47 <skarnet> so I'm on the side of -e.
21:47 <TemptorSent> skarnet: Hopefully, it will reboot to a sane default live config.
21:48 <kaniini> i believe in secure boot case, we are required to reboot
21:48 <kaniini> at least that is my understanding of the spec
21:48 <skarnet> there's a spec for that? o.O
21:48 <TemptorSent> kaniini : That's my understanding too, but I don't think this will get us as far as meeting it completely anyway.
21:48 <kaniini> yes, for EFI secure boot there is a spec
21:48 <skarnet> and it says "if your boot is failing, you have to reboot in a loop, because who cares about wasting power"
21:49 <kaniini> you are supposed to reboot with cause EFI_SECURITY_VIOLATION
21:49 <kaniini> which is supposed to break the loop
21:49 <TemptorSent> kaniini : How do I assert that?
21:49 <kaniini> through some handwavey shit
21:49 <kaniini> TemptorSent: i do not know :/
21:49 <TemptorSent> Bloody hell..
21:49 <TemptorSent> For now, it reboots after 5 seconds.
21:49 <skarnet> there may or may not be an argument to reboot()
21:50 <skarnet> that's supposed to handle this
21:50 <skarnet> but if Linux doesn't support the "reboot with such or such cause" thing, there's not much you can do from userspace
21:51 <TemptorSent> skarnet: Probably something to be written to the EFI security file system.
21:52 <kaniini> i'm not sure. there's not much said about it.
21:52 <TemptorSent> skarnet: I haven't gotten there yet, right now, it fails and bails, which the bootloader can trap an fail-safe if it wants.
21:52 <kaniini> i believe they only deal with checking the initramfs itself
21:52 <kaniini> (the blob)
21:52 <kaniini> and then grub or whatever exits EFI_SECURITY_VIOLATION
21:52 <kaniini> but the spec itself says we should exit EFI_SECURITY_VIOLATION
21:52 <TemptorSent> That makes sense.
21:53 <TemptorSent> We'll implement when we know how, in the mean time, we can at least fail in a state that doesn't leave intersting information sitting there.
21:54 <skarnet> "in case of a security violation, just mount the EFI filesystem and write to it"
21:54 <TemptorSent> If we were booting with keys from a fob or something, we dont' want to leave them in hot-mem.
21:54 <skarnet> sounds perfectly safe
21:55 <TemptorSent> skarnet: Yeah, I didn't make it up.
21:55 <TemptorSent> Essentially some NVRAM register sets IIRC
21:55 <kaniini> skarnet: yeah considering rm -rf efivarfs can brick some EFIs
21:55 <skarnet> exactly
21:56 <skarnet> we don't want to do the same mistakes as systemd, now, do we?
21:56 <TemptorSent> hence the reason we might need to mount sys :/
21:56 <TemptorSent> skarnet: Also the reason I'm wanting to be cautious about what might be mounted at boot that we don't expect.
21:57 <kaniini> well, there is also the problem that
21:57 <kaniini> EFI_SECURITY_VIOLATION is platform-specific
21:57 <TemptorSent> skarnet: I think my loop should handle corner cases.
21:57 <skarnet> we should check, but normally efivars should not be mounted by the kernel
21:57 <kaniini> i.e. my Xserve G5 isn't going to support that
21:57 <skarnet> it breaks the userspace contract if it is
21:57 <kaniini> on the other hand, my Xserve does not support secure boot anyway
21:57 <kaniini> ;)
21:58 <TemptorSent> skarnet: Right, but I think we've come to realize that a lot of real-world cases break that contract and we have to handle them sanely.
21:58 <skarnet> no, not a lot
21:58 alacerda joined
21:58 <skarnet> I don't think anything does
21:58 <skarnet> it's worth checking just to be sure
21:58 <TemptorSent> I mean the init contract, not necessarily the kernel mount, but what gets passed from initramfs to real-root init
21:59 <skarnet> yes, the /sbin/init contract is merrily broken, but that doesn't concern the start of your /init
21:59 <TemptorSent> skarnet: everything from some network file systems to craziness like bootchart!
21:59 <skarnet> atm you're concerned with the kernel -> /init contract
22:00 <TemptorSent> skarnet: Right, and I've been asked to support bootchart...
22:00 <TemptorSent> skarnet: Which I don't really know how to do in a trustworthy way.
22:02 <TemptorSent> Also, fbsplash, and other such fun make it hard to categorically ignore weird mounts and devs at awkward times
22:04 <TemptorSent> skarnet: In fact, I may have to -o move /dev, then clean out the root, then move it back if it is mounted.
22:04 <skarnet> why?
22:04 <TemptorSent> skarnet: That, and check that the device major/minor are correct for the devices we need.
22:04 <skarnet> ls -la | grep -vF /dev is hard
22:06 <TemptorSent> skarnet: Because during crypto checks and possible passwds being typed, we want to make sure there is no way someone spoofed the cpio and got '/dev/null' created with c 4 65
22:07 <TemptorSent> skarnet: There are some very interesting attacks related to spoofing devices or hijacking devfs behavior.
22:07 <skarnet> you're running an initramfs, i.e. pid 1 before anyone can connect
22:08 <skarnet> you KNOW what processes you have
22:08 <TemptorSent> skarnet: I'd rather know exactly what we have.
22:08 <skarnet> you do
22:08 <skarnet> if you can't trust the initramfs you're running from, you can't trust /init either
22:08 <TemptorSent> skarnet: It doesn't require a process, it requires someone to have modified your image subtly.
22:08 <skarnet> that attacker may also have modified /init
22:08 <skarnet> and you've lost
22:09 <TemptorSent> skarnet: The problem is it wouldn't be something you could verify.
22:09 <skarnet> that's my point. *You cannot know*.
22:09 <skarnet> IT's an attack you cannot protect yourself against.
22:09 <TemptorSent> skarnet: I can check sigs and checksums in my early boot.
22:09 <skarnet> useless.
22:09 <skarnet> Unless you're getting them from a more trusted source.
22:10 <TemptorSent> skarnet; but apk verify isn't going to catch an appended cpio that did something funky like that.
22:10 <TemptorSent> That's the whole point, nothing I'm running comes from anywhere but signed packages.
22:10 <skarnet> except /init
22:10 <TemptorSent> I don't trust someone to not have replaced some appended package.
22:11 <TemptorSent> skarnet but I can VERIFY init from both inside and outside the initramfs.
22:11 <skarnet> no you can't
22:11 <TemptorSent> skarnet: And why not???
22:11 <skarnet> it's code you're RUNNING
22:11 <skarnet> if an attacker could tamper it
22:11 <skarnet> it could bypass your verifications
22:12 <TemptorSent> skarnet: I can verify it BEFORE it gets installed in the initramfs,
22:12 <skarnet> Oh, that? Yes. And you can also verify the rest of what you put into your initramfs.
22:12 <skarnet> so, you know exactly what you have.
22:12 <TemptorSent> skarnet: What I can't verify is that nothing APPENDED is malicious.
22:12 <skarnet> which is my point.
22:13 <skarnet> we talked about that already. Don't accept anything appended.
22:13 <TemptorSent> APPEND alpine-initfs, local-initfs, malicious-initfs
22:13 <TemptorSent> skarnet: How do I avoid it, it's a kernel function.
22:14 <TemptorSent> The kernel literally just takes all the appended files as a single stream.
22:14 <skarnet> ... that's terrible.
22:15 <TemptorSent> skarnet: Yup, that's how it works.
22:15 <skarnet> we may need to patch the initramfs loader.
22:15 <TemptorSent> skarnet: Yeah, and every bootloader!
22:15 <skarnet> there should be a kernel option we hardcode to use the baked-in initramfs and nothing else.
22:15 <TemptorSent> skarnet: Which is why I'm trying to have some sanity checking.
22:16 <skarnet> what happens if malicious-initfs overwrites /init
22:16 <TemptorSent> skarnet: Just baking in a verified stub would solve it as long as we only extract verified tarballs.
22:16 <TemptorSent> skarnet: The semantics of cpio should keep that from happening, but thigns like links are not so safe.
22:17 <skarnet> if we can't bake in a stub and make sure everything else is rejected, it's hopeless
22:17 <TemptorSent> skarnet: Well, we can at least make it such that any other attempt to boot fails because the canary doesn't sing.
22:18 <TemptorSent> skarnet: At least without an individually targeted attack, which significantly reduces the exposure.
22:18 <skarnet> I dislike confinement at the dev level
22:18 <TemptorSent> So when you install it, you generate a new disposable key every time.
22:19 ammunta joined
22:19 <skarnet> confinement is for admins who have to deal with shitty software
22:19 <skarnet> at the dev level, we should not confine, we should make sure the right thing is done, period
22:19 <TemptorSent> skarnet: No key, your userspace pukes.
22:19 <TemptorSent> skarnet: Agreed, but until the real world catches up to our utopia, we have to make things work.
22:20 <TemptorSent> skarnet: The trick is using the least-ugly solution
22:20 <skarnet> that's a sysadmin's reaction
22:20 <skarnet> a dev's reaction is to code the solution that works if it doesn't exist yet
22:20 blueness joined
22:21 <TemptorSent> skarnet: No, it's a miner's reaction :)
22:21 <TemptorSent> skarnet: The problem is there is code that exists that we need to coexist with for at least the forseable future.
22:21 ammunta joined
22:22 <TemptorSent> skarnet: Until we can fix the HARDWARE issue, fixing boot is going to be a hack.
22:22 <skarnet> please grow some spine. We're Alpine. ncopa and kaniini weren't afraid to maintain a grsec fork.
22:23 <skarnet> a kernel patch that enforces a fixed baked-in initramfs should totally be in our capacity.
22:23 <TemptorSent> skarnet: That's not the issue -- it's BIOS/EFI
22:23 <TemptorSent> skarnet: Right, but how do we handle cases we're not the kernel vendor?
22:24 <TemptorSent> Do we build rpi kernels for instance?
22:24 <TemptorSent> Talk about a bot-net in the making!
22:24 <skarnet> we'll have to. Else, deal with kernel vendors for a security approval process.
22:24 <TemptorSent> Obviously, those have entirely different issue,s but it's a mess.
22:24 <skarnet> If they won't, no trusted boot, end of story.
22:25 <kaniini> TemptorSent: we do build our own rpi kernel :)
22:25 ammunta joined
22:25 <TemptorSent> skarnet: The point is we can handle most corner cases with a good stub by eliminating the vectors to alter the boot process.
22:26 <TemptorSent> skarnet: We can't meet secure-boot wihout some further work, but we can make it pretty damn hard for automated attacks to make any headway.
22:26 <skarnet> that's exactly what I am suggesting, with a 100% certainty rate, whereas yours is confinement
22:26 <kaniini> what if the malicious initramfs replaces the hash file
22:27 <skarnet> ^
22:27 <skarnet> or the /init code, which is my initial point
22:27 <skarnet> it's not supposed to be able to - how certain are we of that?
22:27 <TemptorSent> kaniini: You can verify the initramfs from OUTSIDE because each of the tar files are signed and the hashes for the tools are themselves in a signed file.
22:28 <TemptorSent> kaniini: The problem I'm trying to solve is that there is at current no way to verify that the initramfs you're booting is made up of trusted files.
22:28 <kaniini> TemptorSent: the bootloader needs to verify the files first
22:28 <kaniini> it's a chain
22:28 <kaniini> you trust the firmware, the firmware trusts the bootloader, the bootloader trusts the kernel + initramfs, the initramfs trusts its contents
22:29 <TemptorSent> kaniini: So I'm using an init with a baked in set of keys/hashes and only using the tools that match those, then using those tools to verify the keys for the rest of the files we extract.
22:29 <kaniini> anyway, fixing the append issue is easy
22:29 <kaniini> we just allow one append
22:29 <TemptorSent> kaniini: So somebody doesn't do something slick like appending a few hundred bytes to the end.
22:29 <kaniini> i am certain this is something we can arrange for
22:30 <TemptorSent> kaniini: Actually, we just want hashed appends :)
22:30 <skarnet> no, just one baked-in.
22:30 <kaniini> wouldnt we want just one append
22:30 <kaniini> and let your shim deal with the rest?
22:30 <TemptorSent> kaniini: If a hash at the beginning matches the hash for the whole thing, we're good.
22:30 <skarnet> KISS
22:30 <skarnet> one stub
22:30 <skarnet> screw the rest
22:31 <kaniini> the way it should work is
22:31 <kaniini> one stub
22:31 <TemptorSent> kaniini; The appends are how the tar.gz files with the modules etc get IN.
22:31 <kaniini> that seems fragile
22:31 <TemptorSent> kaniini: If we do that, we have to bake all modules in too.
22:31 <TemptorSent> kaniini: How so?
22:31 <kaniini> i guess i would need to see this in practice to know
22:31 <kaniini> can you prepare some demo of it
22:32 <skarnet> the cpio appends are how the modules get in? ouch.
22:32 <TemptorSent> Create .tar.gz file with needed modules and userland for say zfs, abuild-sign the file, cpio the result.
22:32 <skarnet> in that case you effectively can't protect against malicious appends.,
22:32 <TemptorSent> skarnet: How else? They're currently all baked in with no hashing or signatures.
22:32 <kaniini> imo
22:33 <TemptorSent> skarnet: I can wipe anything out that's not something I put there or checked the sigs on.
22:33 <kaniini> this seems fragile
22:33 <kaniini> the stub initramfs should have enough to open and verify the other initramfs 'modules'
22:33 <TemptorSent> kaniini: Shall we leave it the way it is, with NO verification?
22:33 <skarnet> open and verify, yeah, but where should it find them
22:33 <skarnet> that's the question
22:33 <kaniini> you make it sound like it is either/or
22:34 <kaniini> skarnet: boot device?
22:34 <TemptorSent> kaniini: We have no access.
22:34 <skarnet> kaniini: catch-22
22:34 <kaniini> yes, what i am saying is, include a base set of modules
22:34 <kaniini> inside the stub
22:34 <TemptorSent> We ONLY have what is loaded in ram to the initfs, which is rootfs mounted at / and read from a cpio archive.
22:35 <skarnet> the point of the modules is to give you what you need to access the boot device
22:35 <TemptorSent> kaniini: ....for?
22:35 <kaniini> oh, i see
22:35 <kaniini> well in that case
22:35 <kaniini> i'm not sure
22:35 <kaniini> :D
22:35 <TemptorSent> kaniini: Yeah, we're talkng many, many modules potentially.
22:35 <kaniini> oh, i see what you are trying to do
22:35 <kaniini> you're trying to do something like what freebsd does
22:35 <TemptorSent> What I have should make all but TARGETED attacks very difficult.
22:35 <kaniini> except linux sucks and we cant prelink the kernel and boot it
22:36 <kaniini> so we have to have a bunch of cpio files
22:36 <TemptorSent> basically, yes.
22:36 <skarnet> cpio appends sound reasonable but man, if an attacker can add any file he wants to your initramfs, this will be HELL to secure
22:36 <TemptorSent> And the kernel will load at least it's internal cpio archive with /dev/console if nothign else.
22:36 <skarnet> no
22:36 <skarnet> the kernel should mount a devtmpfs
22:36 <TemptorSent> skarnet: Right, that's why I DELETE everything that I can't verify
22:36 <skarnet> no way around it
22:37 <TemptorSent> skarnet: Not by my understanding.
22:37 <kaniini> if there is something inside the init environment that is unverifiable, it is a security violation
22:37 <kaniini> deleting is not enough
22:37 <kaniini> it must fail
22:37 <TemptorSent> skarnet in fact, I checked in kvm :)
22:37 <skarnet> it's much easier to trust the kernel than a static /dev
22:37 <kaniini> i agree on devtmpfs
22:38 <TemptorSent> kaniini: Why? I can warn about it, but there is nothing there that doesn't pass key verification.
22:38 <TemptorSent> kaniini: Oh, and I turn of exec for / until we're done :)
22:38 <kaniini> because it means the device has been tampered with
22:38 <skarnet> no sane system is going to use a static /dev in 2017 anyway
22:38 <kaniini> which means the firmware could be tampered with
22:38 <kaniini> which means you're still owned
22:38 <kaniini> thusly, it must fail
22:38 <TemptorSent> skarnet: Actually, static dev is still VERY common, especially in embedded stuff.
22:38 <TemptorSent> kaniini: No, it just means we have a bad append.
22:39 <kaniini> yes, which is a security violation
22:39 <skarnet> I said "no sane system" and I stand by it
22:39 <skarnet> you don't want to know how many embedded systems I've built and deployed with a static /dev
22:39 <TemptorSent> skarnet: Okay, but take a look at other implementations and let me know how they work.
22:39 <TemptorSent> skarnet: Right, and those are pretty common still.
22:40 <skarnet> so what? are they running Alpine?
22:40 <TemptorSent> skarnet: Also, we don't necessarily WANT to see all of the devices early for security reasons.
22:40 <kaniini> TemptorSent: really, if someone has damaged the boot process, we should fail
22:40 <kaniini> i am pretty sure that is the only sane interpretation of the secure boot spec too
22:40 <TemptorSent> skarnet: That's MY plan :)
22:40 <skarnet> devtmpfs won't see all the devices before you mount /sys and coldplug
22:40 <TemptorSent> skarnet: I'd love to get rid of the one-off crap.
22:41 <skarnet> what
22:41 <skarnet> it's init, you can't escape one-off stuff
22:41 <TemptorSent> skarnet: In my embedded projects using some one-off distro.
22:41 <TemptorSent> not init :)
22:41 <skarnet> oh
22:41 <skarnet> so
22:41 <skarnet> today there's NO benefit in using a static /dev over a devtmpfs
22:42 <skarnet> so let people who want it do it
22:42 <TemptorSent> skarnet: Right -- okay, so give me the boot opts that will secure my devtmpfs and we'll go with that.
22:42 <skarnet> but you don't have to support it on a distro YOU own
22:42 <skarnet> no boot options, just a kernel option to tick at kernel build time
22:43 <TemptorSent> skarnet: What devs am I guarenteed to have when I first mount the devtmpfs?
22:43 <kaniini> console
22:43 <skarnet> console and null
22:43 <skarnet> that's it
22:43 <skarnet> in practice Linux provides a few more
22:49 <TemptorSent> skarnet: I also need /dev/kmsg, and do not want any ptys or block devices.
22:50 <skarnet> you should have kmsg
22:50 <skarnet> you won't have any ptys if you don't mount /dev/pts
22:51 <skarnet> block devices, I'm not sure. You won't have any if the block device is a module
22:51 <skarnet> block device support layer*
22:51 <kaniini> if you have block devices, it's because we wanted them there
22:52 <TemptorSent> skarnet: Just checked, it has things I explicitly DON'T want, such as /dev/mem
22:53 <skarnet> I don't understand why it scares you
22:53 <skarnet> if you're only running code you've verified, you're fine
22:54 <TemptorSent> skarnet in fact, it has bsg/, console, cpu_dma_latency, full, grsec, kmsg, mem, memory_bandwidth, network_latency, network_throughput, null, ptmx, random, rtc0, tty*, ttyS*, urandom, vcs* , zero
22:55 <skarnet> yup
22:55 <skarnet> ttyS* means you have serial support baked-in
22:55 <TemptorSent> skarnet: Right.
22:55 <skarnet> grsec means you have grstupidity activated
22:55 <skarnet> rtc0 means you have RTC support baked-in
22:56 <skarnet> vcs* is some vesa console support iirc
22:56 <skarnet> and the rest is pseudo-devices
22:56 <TemptorSent> skarnet: The issue is someone malicious making a link to one of those in the cpio and it getting BEFORE I can verify.
22:56 <TemptorSent> skarnet: Virtual console, yeah
22:57 <skarnet> a link to one of those? good luck with that
22:57 <skarnet> it will have to be a symlink, because cross-dev
22:58 <TemptorSent> skarnet: Why not? doing something like linking to /dev/mem with something would be a really good way of subtly getting something written where it shouldn't be.
22:58 <TemptorSent> or /dev/ttyS0 for that matter.
22:58 <TemptorSent> in a cpio, link /etc/apk/keys to /dev/ttyS0
22:59 <skarnet> sure
22:59 <skarnet> and your legit /etc/apk/keys comes from?
22:59 <TemptorSent> ...Obviously there are more insideous ways.
22:59 <skarnet> not obvious to me
22:59 <jirutka> skarnet: kaniini: TemptorSent: could you please sum up your ~1 400 msg discussion into few sentences? :)
22:59 <TemptorSent> skarnet: The point is you can use it to leak anythign written.
22:59 <skarnet> you control /init, you know what you open
22:59 <TemptorSent> jirutka *LOL*
23:00 <skarnet> the files you open already exust
23:00 <skarnet> exist*
23:00 <skarnet> if you need to create files, check they don't already exist first
23:00 <skarnet> if they do, security violation, boom
23:00 <jirutka> ncopa: clandmeter: fabled: what’s your opinion about moving php5 and all dependent pkgs from main to community?
23:01 <TemptorSent> jirutka: The short of it is that in an effort to secure the boot process, or at least make it verifyable, we need to change how we build and install initramfs.
23:01 <skarnet> there's no problem if malicious-initfs can't overwrite files appended by previous initfses
23:01 <jirutka> TemptorSent: hmm, that’s probably worth the reading
23:01 <jirutka> TemptorSent: btw any progress with ABI breakage detection? :)
23:01 <skarnet> if it can overwrite files, then it's impossible to secure and we need to find another model
23:01 <jirutka> another model or another kernel? :P
23:01 <TemptorSent> skarnet: It's writing files out of sequence that is a concern.
23:02 <kaniini> jirutka: ACK
23:02 <jirutka> the sad truth is that Linux is not designed with security in mind…
23:02 <kaniini> jirutka: if php7 is in community, so should php5
23:02 <TemptorSent> jirutka: I haven't actually played with it any further, but the two leads from a couple days ago look very promising.
23:02 <TemptorSent> jirutka: True statement.
23:03 <TemptorSent> jirutka: Linux was designed with a cool version of minix in mind :)
23:05 <TemptorSent> jirutka: Re ABI breakage detection, see 'abidiff' and 'ABI Compliance Checker'
23:06 <TemptorSent> jirutka: Best results would unfortunately be run against libs with full debug symbols...
23:06 <skarnet> writing files out of sequence? you mean at cpio unpack time?
23:06 <TemptorSent> skarnet: of the appended cpios, yes -- if they were appended in different order, we could have a problem.
23:07 <TemptorSent> skarnet: baking in th stub and nuking the rest fixes that.
23:07 <TemptorSent> skarnet: I wipe the environent completely clean too.
23:07 <skarnet> uuuuh, yes, definitely, you have a problem if you can't guarantee that the files you do have are all legit ones
23:08 <skarnet> if a malicious cpio can completely take over a later, legit cpio, then what do you expect to be able to do
23:08 <TemptorSent> skarnet: Right, basically I'm treating everything but the FIRST cpio loaded as an untrusted pile.
23:08 <skarnet> ok, I want my hour and 2 minutes back
23:08 <TemptorSent> skarnet: So I have to nuke the ENTIRE dir structure except what I explicitly verify and copy.
23:08 <TemptorSent> :)
23:09 <skarnet> there's _no way_ you can possibly make that secure
23:09 <TemptorSent> skarnet: If we can bake in the first stub, any subsequent appends can't overwrite anything dangerous.
23:09 <TemptorSent> skarnet: We can verify the initramfs has the right content BEFORE anything is appended
23:10 <TemptorSent> skarnet: What we don't know is what will be appended, so we can't verify anything past the first portion.
23:10 <skarnet> I said I wanted my time back, not that I wanted to spend more time discussing this
23:11 <TemptorSent> skarnet: Imagine how I feel -- I actually coded it.
23:11 <TemptorSent> All I need to know at this point is whether to move forward or just go back to letting it do what it does currently.
23:12 <TemptorSent> Because right now we have absolutely nothign we can verify in the initramfs, before, during, or after the fact.
23:13 <skarnet> there's probably something to salvage, because you've obviously thought about it a lot, but honestly, I've been working a full day *and* a full evening and I'd like to go do something else before going to sleep
23:13 <kaniini> i think we allow the bootloader to verify it
23:13 <skarnet> so how about saving it for another time
23:14 <TemptorSent> All my stub does is allows you to verify what you install vs. signature, then sanity checks that either what we're running matches what we expect, or someone went throuh a hell of a lot of effort to target us specifically.
23:15 <TemptorSent> skarnet: By all means, you go and have a life -- my lack of one isn't your problem ;)
23:15 <TemptorSent> kaniini: Which bootloader?
23:15 <kaniini> it's an opaque statement
23:15 <kaniini> whichever one you like
23:15 <kaniini> unfortunately, in practice, this probably means grub
23:15 <TemptorSent> kaniini: Most don't support it unfortunately.
23:15 <kaniini> grub does
23:15 <TemptorSent> Yeah, grub or some EFI.
23:16 <TemptorSent> kaniini: Which is about 20% of installed base and 0% of what I have :)
23:17 <TemptorSent> kaniini: Look at it this way, what currently happens when you upgrade your kernel?
23:17 <TemptorSent> kaniini: What comes from where and how?
23:29 <TemptorSent> jirutka: To be honest, I got sidetracked by the boot process verification issue while I was in the middle of trying to fix init and update-kernel.
23:31 <TemptorSent> jirutka: We're taking a signed kernel package, then splitting it out to a bunch of UNSIGNED files in multiple locations, and installing an unsigned initramfs, to which can be appended any random crap (some useful, some not)
23:32 <TemptorSent> jirutka: And, one we've installed the new kernel, we have absolutely nothing to verify the integrity of the kernel, modules, or initramfs componetnts ever again.
23:34 <TemptorSent> jirutka: I'm trying to build a means of verifying at least that the user can trust that what's being run is what he intended to install, if nothing else.
23:35 <TemptorSent> jirutka: Something that can be checked with apk verify against trusted keys.
23:37 <TemptorSent> jirutka: Which would be less of a trust level than a complete secure-boot would require, mostly because we would have to have the bootloader verify the kernel and have the kernel have our stub baked in and not allow subsequent appends to write to most of the /rootfs
23:37 <TemptorSent> jirutka: I think that's the short of it anyway :)
23:39 <TemptorSent> So my proposal gives us at least this: The user installs new kernel, it auto-generates a signing key which signs everything installed in the initfs, and counter-signs the main apk keys.
23:40 <kaniini> how do we know to trust that key
23:40 <TemptorSent> The original kernel files are hashed, and the hash signed with the same key.
23:40 <kaniini> or rather: how do we know we can trust that key
23:41 <TemptorSent> We don't worry about trusting the key, we worry about if it's tampered or not.
23:41 <TemptorSent> So the apk doesn't verifyt
23:41 <kaniini> what if an attacker makes you auto-sign the statement "I murdered the President"
23:41 <TemptorSent> *LOL*
23:41 <kaniini> that's not a joke
23:42 <TemptorSent> We're talking about a user knowing that the modules he installed when he ran update-kernel actually came from the kernel package.
23:42 <TemptorSent> And checking that they're STILL the same ones he installed when he boots.
23:42 <kaniini> okay, but you are generating a key that is associated with a specific user
23:42 <TemptorSent> kaniini: It's a nonce.
23:42 <kaniini> so the key is destroyed afterward?
23:43 <TemptorSent> So every time a user runs update-kernel and installs new initfs, it is a fresh key.
23:43 <TemptorSent> kaniini: Yes, generated in a ramfs that's nuked
23:43 <kaniini> fair 'nuff
23:43 <TemptorSent> kaniini: that is just to provide self-consistency checking.
23:44 <TemptorSent> kaniini: If we can't generate the same private key, we can't force apk verify to accept an altered package.
23:45 <TemptorSent> So we'd have to have a very targeted attack to boot with malicious code unknowingly.
23:45 <TemptorSent> kaniini: Encrypt a key in a package that apk refuses to open in early boot, nothing happens.
23:45 <kaniini> ok
23:46 <TemptorSent> kaniini: Like I said, it's not secure-boot, but it's self-consistent and verifyable boot
23:46 <TemptorSent> kaniini: You'd have to replace more than a few bytes to trick it into doing something evil.
23:47 <TemptorSent> kaniini: Which would make a transparent attack MUCH more difficult.
23:47 <kaniini> its a good step
23:48 <TemptorSent> If you want to store your nonces on a keychain, you can even make sure no sequence attacks have taken place.
23:49 <TemptorSent> Each private signs the public of the previous, so you can verify one came before another.
23:49 rdutra joined
23:50 <TemptorSent> kaniini: Like I said, no miracles, but something I can actually check and verify against the original kernel files
23:51 <TemptorSent> Matching public nonce against signed manifest of hashes, compare hashes against signed kernel packaeges (which we counter-signed, remember?)
23:51 <TemptorSent> we can do an offline verification that actuall means something that way.
23:52 blueness joined
23:53 <TemptorSent> So, with that goal and set of constraints in mind, what do I need to do to the stub I'm working with to meet our needs?