[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH v2] Support for PAX extended header and Linux extended attributes



On 05/23/2016 05:50 AM, Guillem Jover wrote:
Hi!

On Thu, 2016-05-19 at 11:33:27 -0400, Stefan Berger wrote:
The following patch adds support for the tar pax extended header to the tar
parser so that tar files with pax extended headers containing Linux extended
attributes can be processed by dpkg. Essentially the pax extended header
contains key value pairs that describe file attributes. More information
about the format can be found here:

http://pubs.opengroup.org/onlinepubs/009695299/utilities/pax.html#tag_04_100_13_03

We are particularly interested in the security.ima extended attribute,
which, if available, contains a signature for the following file in the tar
and which we then write as a Linux extended attribute into the filesystem.
First of all, thanks for the patch! I've been looking into this the
past several days, and unfortunately I see some problems with the
proposed implementation and probably with this approach in general.

You're welcome.


Adding PAX support in itself seems very worthwile to me as that would
fix several limitations in the ustar format we support currently (true
LFS), and would make it more portable (no need to use GNU extensions
to support long names).

The PAX support is not complete though, it's missing global header
support, removal of variables, and overridding of the ustar fields,
and it should probably validate the input and disallow some stuff,
like entries encoded in anything not UTF-8.

So with the tests I have been doing, for which I am basically repackaging existing (Ubuntu) packages, the current approach at least seems to work on Linux -- the security.ima extended attribute is written into the filesystem's extended attribute using this patch only.

I know about the global header from the specs but haven't come across it so far that I could test its effects. It seems that 'tar' (not bsdtar, which I haven't played with for this purpose) doesn't produce this header. My logic with the other PAX header extensions, like atime, mtime, etc. was so that these so far haven't contributed to metadata of files, so we can ignore them or selectively enable them later. I believe tar has other means of storing access and modification times for example. What I have done in this patch is basically selectively enabled security.ima.


But what we'd gain in portability by using the specified parts of PAX
we'd lose by using the vendor specific xattr support, which is not
supported everywhere:

   <https://github.com/libarchive/libarchive/wiki/TarExtendedAttributes>

And if we are not going to be portable anyway (dpkg is being used in
many non-Debian derived, nor Linux-based systems), we might as well
use a Debian or dpkg specific vendor namespace. (TBH I'm also slightly
uncomfortable with using the proposed xattr namespace given the history
with its author, but this is certainly not a showstopper.)

The GNU tar tool picks up the extended attributes when requested with --xattrs and stores them as SCHILY.xattr. From what I can see bsdtar stores them as LIBARCHIVE.xattr and in base64 encoded format. If these prefixes are related to the namespace you are referring to, I think we should use those of these tools.


I'm assuming this is primarily (if not exclusively) Linux-specific? Or
are there plans to port it to other kernels?

Our intention is to provide this support primarily for Linux.



Then there's the underlaying assumption that xattrs are going to be
supported and enabled by the build-time and install-time systems. Some
time ago when I checked, xattrs were not universally supported by all
filesystems, and were not even enabled by default, has this changed
significantly? I see that Linux supports xattrs for most major ones,
though. I've not checked the status on other Unices yet.

Ubuntu for example has xattrs enabled.

You may notice that I am not checking the result of the syscall that's setting the extended attribute. One reason is that Linux containers, when not privileged (CAP_SYS_ADMIN missing), cannot set the trusted and security extended attributes. So installation of a package inside a container will neither fail nor be very verbose.



Also to be able to store xattrs under the security namespace requires
privs, which most build daemons and build systems do not have. OTOH
fakeroot does have xattr support, so that would cover that. I'm not
sure if other non-root methods support those too.

There's also the possible problem with reproducibility and who is
supposed to sign those files, the builder, some other intermediate
party who has the distribution private keys, etc. If they need to be
injected, it might be better to store them in an additional .deb
member, in a similar way as the proposed .deb container signatures
in something like the sigs.tar.xz ar member.

Yes. For signature verification an additional package should be provided by a repository. This package should contain the key that was used by the distro to sign the files inside packages. This key would then be installed into /etc/security/ima and loaded into the kernel keyring as part of a system boot. It may need to be certified, depending on the setup of the system and which particular keyring is being used (non-trusted vs. trusted).



In the end it might perhaps make more sense to use some other kind of
manifest file to transport additional file attributes, although using
PAX file keywords seems very appealing indeed. I'm working on adding

Well, and the tar tool already picks up the file extended attributes when it creates the tar. So we get the tar support for extended attributes already for free.

mtree(5) support, which I hope to get ready soon, but I'm still uncertain
if that would be ideal as that manifest.


I guess this all depends a bit on how this all is intended to be used.

In the future, ideally distros would provide repositories with packages where the contents are signed. Whether the installed system is actually using them would be up to the user, though having them in the packages enables one to setup a rather locked-down secure system.

Regards,
   Stefan


Thanks,
Guillem



Reply to: