Path traversal allows escaping from altroot

[GregorKopka]

System information

OpenZFS Version | any

Describe the problem you're observing

Path traversal allows escaping altroot specified on zpool import

Describe how to reproduce the problem

$ zpool create pool ...
$ zfs create pool/normal -o mountpoint=/abspath
$ zfs create pool/traverse -o mountpoint=/../../../../traverse
$ zpool export pool
$ zpool import pool -R /altroot
$ zfs list pool -r -o name,mountpoint
NAME             MOUNTPOINT
pool             /altroot/testpool
pool/normal      /altroot/abspath
pool/traverse    /altroot/../../../traverse
$ zfs list /traverse -o name,mountpoint
NAME             MOUNTPOINT
pool/traverse    /altroot/../../../traverse

Include any warning/errors/backtraces from the system logs

None.

[stale[bot]]

This issue has been automatically marked as "stale" because it has not had any activity for a while. It will be closed in 90 days if no further activity occurs. Thank you for your contributions.

[GregorKopka]

This instant system compromise available to everyone allowed to import a pool is still possible.

[amotin]

altroot was never expected to help with that. Its purpose is merely to not mount file systems of imported pool on top of anything existing. I am not sure what you are asking is actually possible or reasonable to implement at file system level.

[GregorKopka]

I disagree strongly, asaltroot is advertised as

Alternate root directory. If set, this directory is prepended to any mount points within the pool. This can be used when examining an unknown pool where the mount points cannot be trusted, or in an alternate boot environment, where the typical paths are not valid.

It is expected to help with exactly that, as it is the sole function of this feature.

This path traversal bug is a security vulnerability with a CVS Score of 6.4

[GregorKopka]

@behlendorf and @ahrens, please take a look at this security issue.

[amotin]

Ah. Sorry, for some reason I thought you are talking about symlinks and their used by applications. Use of ".." in mountpoint properties seems weird. I never saw it in a wild. I am not even sure what behavior would be considered proper here.

[IvanVolosyuk]

May be just fail to mount it with altroot. Seem like a minimal isolated fix. Alternatively, outlaw '..' in mountpoint properties and reject the receive which can be pretty scary.

[GregorKopka]

Alternatively, outlaw '..' in mountpoint properties [...]

or through https://github.com/openzfs/zfs/issues/12997#issuecomment-1248291866, which would also remove another security issue with zfs allow mountpoint (and possibly also the circumvention of the linux limitations regarding mounting of filesystems through sudoers entries that start withzfs set mountpoint=./ and zfs mount x/ (with x being the base dataset assigned to the user)).