On Tue, 2021-02-02 at 14:07 +0100, Ludovic Courtès wrote: > OK, I see. Roughly, this symlink chown story would be a local exploit > that the attacker can take advantage of after exploiting the RCE to > potentially get root access. > > ‘mkdir-p/perms’ could check that the directory is not a symlink, to > begin with. Is this what you had in mind, Maxime?
Yes! Though the parent- and grandparent and etc. should be checked as well. If e.g. (I don't have a real example at hand) knot's activation has a (mkdir-p/perms "/var/lib/knot/e/t/c/e/t/e/r/a" uid/gid-stuff) line, then mkdir-p/perms has to take care that the "e", "t", "c", "e", "t", "e, "r" and "a" directories aren't symlinks. I don't know how I should implement this properly in Guile, though. In C, I would use loop using openat with O_NOFOLLOW, in combination with stat, but Guile doesn't have openat or O_NOFOLLOW. I've proposed adding the O_NOFOLLOW to guile [1]. I don't have a proposal for openat in guile yet. If I do propose an interface to openat(2); I should probably make a proposal for fchownat and other *at variants at the same time. I don't have a concrete proposal for how a nice Scheme interface would look like. In the mean time, I suppose it should be possible to use openat via the FFI and define O_NOFOLLOW manually in Guix. I'll look into writing a concrete proposal for *at in guile. I'll post a link to the guile mailing list message when it has been composed and sent. Greetings, Maxime. [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46220
signature.asc
Description: This is a digitally signed message part
