Post APwEMlnf9TzvzhZDTE by drewdevault@fosstodon.org
(DIR) More posts by drewdevault@fosstodon.org
(DIR) Post #APvm2n0m8mFBF9NuKG by bug@fosstodon.org
2022-11-24T13:41:47Z
0 likes, 1 repeats
Question for the #infosec folks out there: are you aware of a way for the atime file updates to "escape" a container somehow?In case that's not obvious, I'm wondering if it's possible for a guest to mess with atime on the host in order to trigger #y2k38 bugs there, or at least cause some tampering somehow for other purposes.I'm aware this a broad question given how many different container systems exist, but food for thoughts I guess.
(DIR) Post #APvm2nXOBWKcsIdxA0 by wolf480pl@mstdn.io
2022-11-24T14:02:01Z
1 likes, 0 repeats
@bug I'm no expert but I did work with Linux namespaces a bit, and AFAIU, it boils down to:Do you have some filesystem mounted both inside and outside of the container?Eg.- is resolv.conf from host bind-mounted in the container?- is container's rootfs mounted on host under /var/lib/docker or equivalent- are there temporary storage volumes, or credentail volumes, that are mounted both in host and in the conatiner?etc.
(DIR) Post #APvxZ8ciQFLD2Al4oi by bug@fosstodon.org
2022-11-24T16:10:54Z
0 likes, 0 repeats
@wolf480pl @roomey @johnkapri so if the guest has access to host files mounted in read-only, reading from there would affect the atime?For the question about whether it's for a vm or a container, again it's an open question, I don't have anything specific in mind as I lack knowledge and experience in that area. I was just thrilled by having my user modify metadata of system protected files and causing a mess because of it. And I actually can't stop thinking about that lately.
(DIR) Post #APw3abfUWGrD858kMa by roomey@mastodon.ie
2022-11-24T16:56:49Z
0 likes, 0 repeats
@bug @wolf480pl @johnkapri I guess it depends on the mount options and FS type, but you could be onto something there!I would have thought an read only mount would/should prevent atime writes
(DIR) Post #APw3ac78rSyWVq4pSi by wolf480pl@mstdn.io
2022-11-24T17:18:41Z
0 likes, 0 repeats
@roomey @bug @johnkapri If you mount it with noatime or relatime, I think it should be fine, but that's very implementation dependent, and eg. if someone has root inside a container, they may be able to change the mount flags.If you want something to be really read-only, you can make the block device read-only (blockdev --setro on Linux) and then you can be sure nothing will change atime on disk, but if the same device needs to be written to by host, that won't work...
(DIR) Post #APwEMlnf9TzvzhZDTE by drewdevault@fosstodon.org
2022-11-24T18:07:15Z
0 likes, 0 repeats
@bug speculating here, but I think the risk associated with this is pretty low. You can only forge atimes on files you have write access to and which match your uid.
(DIR) Post #APwEMmKz9aeXf39pPU by wolf480pl@mstdn.io
2022-11-24T19:19:26Z
0 likes, 0 repeats
@drewdevault @bug unless you have CAP_FOWNER or similar, right?As an experiment, I started a docker container with a shell in it - it ran root inside as default - and checked its capabilities from the outside.It had, among other things: cap_chowncap_dac_overridecap_fownercap_fsetidThen I checked its userns. It was the same as any process outside the container.tl;dr many things run as real root inside a container by default, with enough caps to override fs permissions.
(DIR) Post #APwERUnnmDCkiysxrk by drewdevault@fosstodon.org
2022-11-24T19:20:15Z
0 likes, 0 repeats
@wolf480pl @bug if you're running as root (or using caps, which on Linux is basically the same as running as root) then all bets are off. Don't run as root.
(DIR) Post #APwEfsEXSN0ZRvFOk4 by wolf480pl@mstdn.io
2022-11-24T19:22:53Z
0 likes, 0 repeats
@drewdevault @bug Yes.Running as root inside containers is a bad idea.Letting users run as root inside containers is a bad idea.Running as "root" in a userNS may be a less bad idea unless userNS implementation is buggy, so who knows.