GNU bug report logs - #73166
'shell-authorized-directories' located in the wrong place?

Previous Next

Full log

View this message in rfc822 format

From: Saku Laesvuori <saku <at> laesvuori.fi>
To: Nicolas Graves <ngraves <at> ngraves.fr>
Cc: 73166 <at> debbugs.gnu.org, ludo <at> gnu.org, suhailsingh247 <at> gmail.com, andrew <at> trop.in
Subject: bug#73166: shell-autorized-directories
Date: Thu, 14 Nov 2024 13:07:36 +0200

[Message part 1 (text/plain, inline)]

On Tue, Nov 12, 2024 at 05:49:13PM +0100, Nicolas Graves wrote:
> On 2024-11-12 09:50, Suhail Singh wrote:
> 
> > I was under the impression that the build phase in guix is always
> > containerized and without network access.  Could you please elaborate on
> > this?
> 
> Building a package yes, but you can have external commands in a
> manifest.scm or guix.scm.  Saku provided an example in an earlier email
> of a valid but dangerous manifest:
> 
> ```scheme
> (system* "rm -rf $HOME")
> (specifications->manifest (list "hello"))
> ```
> 
> We could also have one that downloads malicious code, or uploads private
> info, the POC is left as an an exercice for the reader ;) 
> 
> What I was saying is that we could restrain recording `guix shell --allow`
> only if the manifest builds properly containerized and without network
> access (outside package building I mean), and otherwise refuse to allow
> (failing manifest, possibly because it tries to access the network or
> files outside the repo) with a warning message, providing the ability to
> restrain "automatic loading" to certain "safer" conditions only.
> 
> This would in turn mean that (given the same guix revision) we can
> always run a `guix shell --allow`-ed using `guix shell --container`
> which actually makes a lot of sense in my use-case.  I don't really know
> about other use-cases, but I guess it's the same, even a scheme
> developper would probably want a manifest that doesn't depend on files
> outside of his repo or the network.  Saku, do you have an opinion on
> this?

There are likely some cases where someone would want to define a
manifest that depends on external factors, but I do agree they seem
rare. Probably not in a public project repo but maybe someone would want
to have (for example) different environments in different directories
and some common values in ~/.config that all of them refer to.

> The downside is that we would have to basically run `guix shell
> --container` (and build all there is to build) before being able to run
> `guix shell --allow`.

In the repository manifest use-case this seems to not be a downside (the
user is to build the environment anyway if they authorized it). In other
use-cases this might prevent people from using guix shell --allow even
though their case might be much more secure (like the environments in
different directories sharing common data).

> WDYT?

The only benefit seems to be in situations where the user would want the
shell to be in a container, so maybe in that case the default behaviour
should be to also evaluate the manifest in the container. I don't know
would that be a good choice. It increases security for those who use a
container and don't know that loading an environment is equivalent to
executing the file, but if it leads people assume that loading an
environment is safer than executing a file in general, they have less
security in non-container environments.

We should keep in mind that implicit manifests for guix shell are not
only useful in public repositories.

- Saku

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.