bug#47584: Race condition in ‘copy-account-skeletons’: possible privilege escalation.

[Maxime Devos]

On Sat, 2021-04-03 at 22:33 +0200, Ludovic Courtès wrote:
> Maxime Devos <maximedevos@telenet.be> skribis:
> 
> > The attack consists of the user being logged in after the account
> > skeletons have been copied to the home directory, but before the
> > owner of the account skeletons have been set.  The user then deletes
> > a copied account skeleton (e.g. @file{$HOME/.gdbinit}) and replaces
> > it with a symbolic link to a file not owned by the user, such as
> > @file{/etc/shadow}.
> > 
> > The activation code then changes the ownership
> > of the file the symbolic link points to instead of the symbolic
> > link itself.  At that point, the user has read-write access
> > to the target file.
> 
> In the draft blog post, you mention that the attack cannot be carried
> out when protected symlinks are enabled.

In the blog post, I thought I wrote the attack can be carried out
*even if* protected symlinks are enabled.  Looking at

https://sysctl-explorer.net/fs/protected_symlinks/,

I don't think the Linux protected symlink feature helps, as home
directories are never sticky and word-writable.

Perhaps I should have written ‘possible’ instead of ‘not impossible’
in the blog post.

> Please mention that protected symlinks are enabled by default on Guix
> System since a March 16th commit, with a link to [...]

See my response above.

I agree with all other comments on this bug report.

Greetings,
Maxime.

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