[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Potential security weakness in Guix services
From: |
Maxime Devos |
Subject: |
Re: Potential security weakness in Guix services |
Date: |
Tue, 02 Feb 2021 14:38:23 +0100 |
User-agent: |
Evolution 3.34.2 |
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
- Re: Potential security weakness in Guix services, Ludovic Courtès, 2021/02/01
- Re: Potential security weakness in Guix services, Julien Lepiller, 2021/02/01
- Re: Potential security weakness in Guix services, Maxime Devos, 2021/02/01
- Re: Potential security weakness in Guix services, Ludovic Courtès, 2021/02/02
- Re: Potential security weakness in Guix services,
Maxime Devos <=
- Re: Potential security weakness in Guix services, Maxime Devos, 2021/02/02
- Re: Potential security weakness in Guix services, Ludovic Courtès, 2021/02/05
- Re: Potential security weakness in Guix services, Maxime Devos, 2021/02/05
- Re: Potential security weakness in Guix services, Maxime Devos, 2021/02/05
- Re: Potential security weakness in Guix services, Ludovic Courtès, 2021/02/06
- Re: Potential security weakness in Guix services, Maxime Devos, 2021/02/06
- Re: Potential security weakness in Guix services, Ludovic Courtès, 2021/02/10
- Re: Potential security weakness in Guix services, Ludovic Courtès, 2021/02/06
- TOCTTOU race (was: Potential security weakness in Guix services), Maxime Devos, 2021/02/14
- Re: TOCTTOU race (was: Potential security weakness in Guix services), Bengt Richter, 2021/02/14