Nix: NAR support for extended attributes

[wizeman]

For userspace programs to work properly under a PaX/grsecurity kernel, sometimes we need to mark executables with flags to disable some protections, on a binary-by-binary basis.

The plan was to use the "paxctl" utility to add a PT_PAX_FLAGS header to the ELF binary. However, modifying a binary does not work in all cases (such as programs that self-check their own binary), and general support for PT_PAX_FLAGS is probably going away at some point in the future.

The new approach is to use an extended attribute (xattr) to set these flags, e.g.:

$ setfattr -n user.pax.flags -v "me" /path/to/binary

From a cursory glance it seems, however, that the Nix store currently does not support extended attributes on NAR packages, so these xattrs would be lost when downloading from a binary cache or when copying packages to another system.

[edolstra]

In fact, it's a bug that Nix allows extended attributes to be set at all. canonicalisePathMetaData() should really detect if a file has EAs or ACLs and remove them or barf.

[ts468]

What would need to be done to have EAs available in the nix store? What is the best way I could help?

[vcunat]

I don't even see it's a good way to go. For the case of self-checking binaries, even hash-rewriting might be a problem. Are there some other use cases? Also note the portability problems: what do we do if the target FS doesn't support those attributes?

[spacekitteh]

Is there any support at all for metadata in NAR packages?

[vcunat]

No, IIRC there's basically nothing, "on purpose". This description certainly looks like it: https://github.com/NixOS/nix/blob/master/src/libutil/archive.hh#L10

[spacekitteh]

That's... Strange. Why?

On Sun, 27 Nov 2016, 01:49 Vladimír Čunát, [e-mail] wrote:

No, IIRC there's basically nothing, "on purpose". This description
certainly looks like it:
https://github.com/NixOS/nix/blob/master/src/libutil/archive.hh#L10

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/NixOS/nix/issues/185#issuecomment-263070324, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AB2crANEsPrOVQ89I4KpPdiTso2kDW86ks5rCFUkgaJpZM4BVFFR
.

[vcunat]

You can read about (some of) the original reasoning in Nix Thesis (5.2.1). IMO portability of such metadata is a serious concern.

[spacekitteh]

Indeed, I've already read that. I had hoped it had changed since the thesis.

One wonders whether the adoption of a new archive format such as SquashFS would solve such problems. It's portable, it allows arbitrary xattrs (e.g. hashes of each file/inode in a directory, and a hash of those hashes can be stored as an xattr for the directory itself; this means the layout "on disk" doesn't matter) (another example would be selinux/pax/apparmor flags), great compression, and via things such as union filesystems, can be composed in much more intricate ways than one can with chroot and the like.

[vcunat]

My portability concern was mainly about portable representing these extra metadata in nix store.

Ideally we'd want NAR <-> nix store to be a bijection on each supported platform/FS combination; i.e. you want to go back and forth, nix-copy-closure among different platforms/FS combinations, etc. all without losing or "adding" any information.

[spacekitteh]

Yeah. Obviously it'd put some constraints on supported filesystems. What are the current supported ones, do you know?