[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why is /gnu/store writable by the guixbuild group?
From: |
Ludovic Courtès |
Subject: |
Re: Why is /gnu/store writable by the guixbuild group? |
Date: |
Sat, 23 Jan 2016 21:56:46 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Steven Allen <address@hidden> skribis:
> On 01-22-16, Ludovic Courtès wrote:
>> What’s TPE (sorry for asking) and how does it complain exactly?
>
> Nevermind. This is a false positive and I've reported it to the
> grsecurity people (although they may not fix it...).
>
> FYI...
>
> TPE is Trusted Path Execution. Basically, it means that unprivileged
> users can only execute files that are not writable, or in directories
> writable, by users other than the current user or root. This is to help
> make it harder to trick users into executing files written by a
> malicious user.
OK.
> However, after thinking about it, I this case is a false positive
> because:
>
> 1. The /gnu/store/xxx/ directories and all files under them are not
> group writable and are owned by root.
> 2. /gnu/store has the sticky bit set.
>
> This means that any files in /gnu/store that are owned by root must have
> "blessed" by root (either linked-in or chowned by root). Therefore, the
> "no group/other writable parent directory" constraint is unnecessary.
Indeed. The mental model is that /gnu/store is populated by root, on
behalf of other users. The build users act as a poor way to enforce the
principle of least authority.
>> > Guix on Arch keeps on trying to build gcc on my poor laptop even
>> > though I've enabled substitutes but that's another issue...)
>>
>> That shouldn’t happen, unless you’re using an old version of Guix for
>> which substitutes are no longer available at hydra.gnu.org.
>
> I'm using guix from git and I'll look into it. In my build logs, it
> appears that tar is complaining about an invalid flat ("--sort=name") so
> I think guix is having trouble extracting the substitutes.
I don’t think this is related.
>> That’s because initially build processes write to their chroot, but when
>> the build completes, the build process moves the outputs (the results)
>> back to the store.
> ...
>> If you look at ‘strace -f -p $(pidof guix-daemon)’ while running ‘guix
>> build grue-hunter’, the above lines of code translate to:
>>
>> --8<---------------cut here---------------start------------->8---
>> 7519 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7544,
>> si_status=0, si_utime=0, si_stime=0} ---
>> 7519
>> lstat("/gnu/store/660hdld3sc7laz8kw871pd3yyg9khs5m-grue-hunter-1.0.drv.chroot/gnu/store/h6sdfqzv4xbydwiafiqvrw0d5505l1l8-grue-hunter-1.0",
>> {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
>> 7519
>> rename("/gnu/store/660hdld3sc7laz8kw871pd3yyg9khs5m-grue-hunter-1.0.drv.chroot/gnu/store/h6sdfqzv4xbydwiafiqvrw0d5505l1l8-grue-hunter-1.0",
>> "/gnu/store/h6sdfqzv4xbydwiafiqvrw0d5505l1l8-grue-hunter-1.0") = 0
>> --8<---------------cut here---------------end--------------->8---
>
> I just did a local experiment (running pstree alongside strace) and,
> unless I'm mistaken, 7519 is running as root.
Hmm, I think you’re right. In that case the thing does not need to be
world-writable, we should try and check!
Thanks,
Ludo’.