guix-devel
[Top][All Lists]
Advanced

[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: Fri, 29 Jan 2021 16:25:00 +0100
User-agent: Evolution 3.34.2

On Fri, 2021-01-29 at 14:33 +0100, Maxime Devos wrote:
> Hi Guix,
> [...]
> > Below is a summary of their messages, including a mitigation proposal.
> > Your feedback is requested!
> 
> I'm writing a patch right now.  It's a little more elaborate than my
> mkdir-p/own proposal.  In the patch, directories with owner, group
> and permission bits are created via extensions to a ‘fs-entry-service-type’,
> which will perform various basic consistency checks at build time
> (e.g., no directory can be owned by multiple users).
> 
> I'll post a draft when it's ready.

[First draft is attached, with many parts missing, it doesn't even
compile]
I think I've got a basic idea on how to handle this.
Some problems to address:

* Guile does not have ‘openat, mkdirat’ procedures.
  How to resolve: implement these upstream, write FFI bindings,
  or use 'chdir' carefully.

* Verify whether symlinks are handled correctly.
  (stat vs lstat vs fstatat ...)

* Perhaps O_NOCTTY, O_NOLINK, O_NOTRANS, O_NONBLOCK, O_DIRECTORY,
  O_NOFOLLOW ... need to be used at some places.

* Maybe fsync needs to be used in some places.

  The service definitions don't seem to do that anywhere when chmodding
  and chowning, so not implementing this shouldn't be a regression,
  but it does seem like something to verify.

* On some Linux versions and filesystems,
  the use of O_TMPFILE might simplify reasoning about security properties,
  race windows, etc., but idk if it's supported on the Hurd, and which
  (linux version, filesystem) combinations are supported.

* Mounting filesystems.
  Can all filesystems used by services when activating be assumed to be up?
  idk. 

* Support more security stuff (SELinux, SMACK, POSIX ACL, ...)
  Something for the far future, perhaps?

Perhaps I should just implement the basic mkdir-p/own proposal for now,
and in the future something more elaborate can be implemented?
All but the last two points probably still apply, though.

I'll take a look at how other systems handle this.

Maxime

Attachment: directory-setup.scm
Description: Text Data

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]