Filesystem extended attributes support

[Dewayne Geraghty]

On 5/07/2020 9:15 pm, Shawn Webb wrote:
> 
> Sounds good. Thanks for the positive response. I might try to upstream
> the tmpfs patch as well, but I'm not sure I've got the locking right,
> yet. It's my first time working on a filesystem of any sort, and I'm
> not confident I got it right on the first try. Time will tell.
> 
> With extended attribute support, pkg could also store a hash of the
> file as an extended attribute. One could use that as a method to
> determine whether changes have been made. Think: application integrity
> enforcement.
> 
> So filesystem extended attribute support may have virtues outside of
> HardenedBSD's exploit mitigation toggling use case.
> 
> Thanks,
> 
I like your thinking and appreciate you going to the effort to migrate
features from HardenedBSD.

I look forward to testing with samba which normally uses system,security
and user namespaces; but we (ie Timur) have patched samba to use user
namespace as that is all that can be manipulated within the jail context.

Re: extattr.  Though it might be better to store a signed hash of the
file within the extended attribute as root.  Reasoning is that
applications running as non-root that have access to files, may, if
hacked, change the hash. (assumes only root has access to the signing
key) ;)  Used in combination with mac.portacl is a sleep-easy approach.  :)

I am concerned for those that build their own packages that use
archivers/libarchive.  E.g.
# ldd `which pkg`
/usr/local/sbin/pkg:
        libelf.so.2 => /lib/libelf.so.2 (0x800881000)
        libjail.so.1 => /lib/libjail.so.1 (0x80089a000)
        libarchive.so.13 => /usr/local/lib/libarchive.so.13 (0x8008a2000)
        libbz2.so.4 => /usr/lib/libbz2.so.4 (0x800b60000)
...
as any patch may need to be applied there as well.

Kind regards, Dewayne.