subject:"Possible issue with linux xattr support\?"

* Dmitry Chagin  [20230904 21:49]:
> On Mon, Sep 04, 2023 at 08:43:02PM +0200, Felix Palmen wrote:
> > I guess I'll now do a full rebuild of my linuxulator userspace branch on
> > a kernel with that patch, just to be sure it won't break anything else,
> > this will take a few hours, I will report back. So far looking really
> > good :)

This completed while I was sleeping. No issues!

With ~120 "Linux ports" building fine, using all sorts of tools (like
python and some tools from coreutils), I think it's fair to assume it's
all fixed now.

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

* Dmitry Chagin  [20230904 21:49]:
> On Mon, Sep 04, 2023 at 08:43:02PM +0200, Felix Palmen wrote:
> > Thanks a lot for the quick patch! I have to admit I don't fully
> > understand it immediately, but I assume it's an attempt to only list
> > attributes not in system.* when that namespace is restricted?
> 
> no,
> +   if (error == EPERM)
> +   break;
> mean that listxattr will fail if user is unauthorized to access system
> namespace, ie, listxattr will return ENOTSUP

Ah, now I get it, so breaking out of the loop there will leave
attrnamespace at EXTATTR_NAMESPACE_SYSTEM if that was the cause,
therefore error_to_xattrerror() works as expected. Nice!

Well, given that I really don't expect any further problems, but give my
poor builder a few hours to *really* verify :)

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

2023-09-04 Thread Dmitry Chagin

On Mon, Sep 04, 2023 at 08:43:02PM +0200, Felix Palmen wrote:
> Hello Dmitry,
> 
> * Dmitry Chagin  [20230904 21:29]:
> > Thanks for the report,
> > please, try this: https://people.freebsd.org/~dchagin/lxattr.patch
> > Don't be surprised, there 2 fixes
> 
> Thanks a lot for the quick patch! I have to admit I don't fully
> understand it immediately, but I assume it's an attempt to only list
> attributes not in system.* when that namespace is restricted?

no,
+   if (error == EPERM)
+   break;
mean that listxattr will fail if user is unauthorized to access system
namespace, ie, listxattr will return ENOTSUP

> 
> Well, it *does* solve the issue with 'cp -p' from GNU coreutils!
> 
> I guess I'll now do a full rebuild of my linuxulator userspace branch on
> a kernel with that patch, just to be sure it won't break anything else,
> this will take a few hours, I will report back. So far looking really
> good :)
> 

nice, thanks

> Cheers, Felix
> 
> -- 
>  Felix Palmen  {private}   fe...@palmen-it.de
>  -- ports committer -- {web}  http://palmen-it.de
>  {pgp public key}  http://palmen-it.de/pub.txt
>  {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231

Re: Possible issue with linux xattr support?

Hello Dmitry,

* Dmitry Chagin  [20230904 21:29]:
> Thanks for the report,
> please, try this: https://people.freebsd.org/~dchagin/lxattr.patch
> Don't be surprised, there 2 fixes

Thanks a lot for the quick patch! I have to admit I don't fully
understand it immediately, but I assume it's an attempt to only list
attributes not in system.* when that namespace is restricted?

Well, it *does* solve the issue with 'cp -p' from GNU coreutils!

I guess I'll now do a full rebuild of my linuxulator userspace branch on
a kernel with that patch, just to be sure it won't break anything else,
this will take a few hours, I will report back. So far looking really
good :)

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

2023-09-04 Thread Dmitry Chagin

On Mon, Sep 04, 2023 at 04:03:54PM +0200, Felix Palmen wrote:
> * Felix Palmen  [20230904 15:39]:
> > For some reason (I still have to try to get more information about it,
> > will do soon), something else is broken now. While install from GNU
> > coreutils works fine, some build systems use 'cp -p' to install files
> > instead, which now fails with:
> > 
> > | cp: preserving permissions for [...]: Operation not permitted
> 
> The issue seems to be with listing attributes:
> 
> | root@15-default:/wrkdirs/usr/ports/x11/linuxsrc-libxcb/work/libxcb-1.15/doc 
> # truss /compat/linux/bin/cp -pR ./tutorial 
> '/wrkdirs/usr/ports/x11/linuxsrc-libxcb/work/stage/compat/linux/usr/share/doc/libxcb/'
>  2>&1 | grep xattr
> | linux_flistxattr(0x4,0x0,0x0)ERR#-1 'Operation not 
> permitted'
> | linux_flistxattr(0x4,0x0,0x0)ERR#-1 'Operation not 
> permitted'
> | linux_llistxattr(0xcdd9,0x0,0x0) ERR#-1 'Operation not 
> permitted'
> 
> The following q patch makes it work again:
> 
> #v+
> diff --git a/sys/compat/linux/linux_xattr.c b/sys/compat/linux/linux_xattr.c
> index 74b47f1cbaec..0b5af084b1b1 100644
> --- a/sys/compat/linux/linux_xattr.c
> +++ b/sys/compat/linux/linux_xattr.c
> @@ -198,7 +198,7 @@ listxattr(struct thread *td, struct listxattr_args *args)
> if (error == 0)
> td->td_retval[0] = cnt;
> free(data, M_LINUX);
> -   return (error_to_xattrerror(attrnamespace, error));
> +   return (error_to_xattrerror(EXTATTR_NAMESPACE_SYSTEM, error));
>  }
>  
>  int
> #v-
> 
> I think this makes sense, because listxattr iterates over all
> namespaces, so there's no sane way to know whether the EPERM was caused
> by trying to access "system" or something else.

Thanks for the report,
please, try this: https://people.freebsd.org/~dchagin/lxattr.patch
Don't be surprised, there 2 fixes


> 
> Cheers, Felix
> 
> -- 
>  Felix Palmen  {private}   fe...@palmen-it.de
>  -- ports committer -- {web}  http://palmen-it.de
>  {pgp public key}  http://palmen-it.de/pub.txt
>  {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231

Re: Possible issue with linux xattr support?

* Felix Palmen  [20230904 15:39]:
> For some reason (I still have to try to get more information about it,
> will do soon), something else is broken now. While install from GNU
> coreutils works fine, some build systems use 'cp -p' to install files
> instead, which now fails with:
> 
> | cp: preserving permissions for [...]: Operation not permitted

The issue seems to be with listing attributes:

| root@15-default:/wrkdirs/usr/ports/x11/linuxsrc-libxcb/work/libxcb-1.15/doc # 
truss /compat/linux/bin/cp -pR ./tutorial 
'/wrkdirs/usr/ports/x11/linuxsrc-libxcb/work/stage/compat/linux/usr/share/doc/libxcb/'
 2>&1 | grep xattr
| linux_flistxattr(0x4,0x0,0x0)ERR#-1 'Operation not 
permitted'
| linux_flistxattr(0x4,0x0,0x0)ERR#-1 'Operation not 
permitted'
| linux_llistxattr(0xcdd9,0x0,0x0) ERR#-1 'Operation not 
permitted'

The following q patch makes it work again:

#v+
diff --git a/sys/compat/linux/linux_xattr.c b/sys/compat/linux/linux_xattr.c
index 74b47f1cbaec..0b5af084b1b1 100644
--- a/sys/compat/linux/linux_xattr.c
+++ b/sys/compat/linux/linux_xattr.c
@@ -198,7 +198,7 @@ listxattr(struct thread *td, struct listxattr_args *args)
if (error == 0)
td->td_retval[0] = cnt;
free(data, M_LINUX);
-   return (error_to_xattrerror(attrnamespace, error));
+   return (error_to_xattrerror(EXTATTR_NAMESPACE_SYSTEM, error));
 }
 
 int
#v-

I think this makes sense, because listxattr iterates over all
namespaces, so there's no sane way to know whether the EPERM was caused
by trying to access "system" or something else.

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

Hello Dmitry,

* Dmitry Chagin  [20230830 14:04]:
> Thanks, I see, I agree with your change, taken into account.

Thanks a lot for committing the fix/workaround as well as the new
feature! I just upgraded my test builders to 15-CURRENT to double-check.

For some reason (I still have to try to get more information about it,
will do soon), something else is broken now. While install from GNU
coreutils works fine, some build systems use 'cp -p' to install files
instead, which now fails with:

| cp: preserving permissions for [...]: Operation not permitted

I'm pretty sure this worked fine with the patch you linked earlier, and
also with my own change taking the namespace into account ...

Did you change anything else in your commits compared to the patch?

I'll post a followup as soon as I could get some truss output to know
exactly which syscall causes the issue now!

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

2023-08-30 Thread Shawn Webb

On Wed, Aug 30, 2023 at 06:55:14AM +0200, Alexander Leidinger wrote:
> Am 2023-08-29 21:02, schrieb Shawn Webb:
> 
> > Back in 2019, I had a similar issue: I needed access to be able to
> > read/write to the system extended attribute namespace from within a
> > jailed context. I wrote a rather simple patch that provides that
> > support on a per-jail basis:
> > 
> > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3
> 
> You enabled it by default. I would assume you had a thought about the
> implications... any memories about it?

I hope you don't mind if I quote a response I wrote to another person
on the list about the feature:

=== begin quote ===
In HardenedBSD's case, since we use filesystem extended attributes to
toggle exploit mitigations on a per-application basis, there's now a
conceptual security boundary between the host and the jail.

Should the jail and the host share resources, like executables, a
jailed process could toggle an exploit mitigation, and the toggle
would bubble up to the host. So the next time the host executed
/shared/app/executable/here, the security posture of the host would be
affected.

FreeBSD uses ELF header tagging, not filesystem extended attributes,
to toggle exploit mitigations. So my description above is moot for
FreeBSD users. I'm just hoping to share a unique perspective.
=== end quote ===

The main reason for enabling it by default in HardenedBSD is so that
exploit mitigation toggles get applied to the application on `pkg
install` (or `make install` in ports.) We have patches to our ports
tree and have forked pkg to support the way we toggle exploit
mitigations.

So, I wanted to make sure that applications would behave the same in a
jailed environment and the host... to avoid a POLA violation.

> 
> What I'm after is:
>  - What can go wrong if we enable it by default?

I don't know if there's anything that could go wrong if FreeBSD was to
enable it by default. I think it might be more of a downstream issue:
those who have developed custom behavior backed by filesystem extended
attributes.

>  - Why would we like to disable it (or any ideas why it is disabled by
> default in FreeBSD)?

I wouldn't want to dictate what approach FreeBSD takes, if any. I
think the approach I've taken works well for HardenedBSD. But the
FreeBSD community might prefer an entirely different approach
altogether.

> 
> Depending in the answers we may even use a simpler patch and have it allowed
> in jails even without the possibility to configure it.

I also wonder if extended attributes could be taught to (optionally?)
scope extended attributes to each jail. That might be a topic worth
exploring some day for someone. Just a random thought. :-)

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

On Tue, Aug 29, 2023 at 02:07:11PM -0500, Kyle Evans wrote:
> On 8/29/23 14:02, Shawn Webb wrote:
> > On Tue, Aug 29, 2023 at 05:45:51PM +0300, Dmitry Chagin wrote:
> > > On Tue, Aug 29, 2023 at 12:59:11PM +0200, Felix Palmen wrote:
> > > > * Dmitry Chagin  [20230828 18:57]:
> > > > > On Mon, Aug 28, 2023 at 08:03:33AM +0200, Felix Palmen wrote:
> > > > > > * Cy Schubert  [20230827 16:59]:
> > > > > > > 
> > > > > > > If we are to break it to fix a problem, maybe a sysctl to 
> > > > > > > enable/disable then?
> > > > > > 
> > > > > > IMHO depends on the exact nature of the problem. If it's confirmed 
> > > > > > that
> > > > > > it (always and only) breaks for jailed processes, just disabling it 
> > > > > > for
> > > > > > them would be the better workaround. "No-op" calls won't break 
> > > > > > anything.
> > > > > > 
> > > > > 
> > > > > please, try: https://people.freebsd.org/~dchagin/xattrerror.patch
> > > > 
> > > > Thanks, I can confirm this avoids the issue in both cases I experienced
> > > > (install from GNU coreutils and python).
> > > > 
> > > thanks, this is the first half of the fix, it works for you due to you
> > > are running tools under unprivileged user, afaiu. The second I have
> > > tested by myself :)
> > > 
> > > > If I understand this patch correctly, it completely avoids EPERM,
> > > > masking it as not supported, so callers should consider it non-fatal,
> > > > allowing to silently ignore writing of "system" attributes while still
> > > > keeping other functionality?
> > > > 
> > > system namespace is accessible only for privileged user, for others Linux
> > > returns ENOTSUP. So many tools ignores this error, eg ls.
> > > 
> > > the second: https://people.freebsd.org/~dchagin/sea_jailed.patch
> > > 
> > > Try this under privileged user, please.
> > 
> > Back in 2019, I had a similar issue: I needed access to be able to
> > read/write to the system extended attribute namespace from within a
> > jailed context. I wrote a rather simple patch that provides that
> > support on a per-jail basis:
> > 
> > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3
> > 
> > Hopefully that's useful to someone.
> > 
> > Thanks,
> > 
> 
> FWIW (which likely isn't much), I like this approach much better; it makes
> more sense to me that it's a feature controlled by the creator of the jail
> and not one allowed just by using a compat ABI within a jail.
>


Seems phab mail is dead, https://reviews.freebsd.org/D41643

Re: Possible issue with linux xattr support?

On Wed, Aug 30, 2023 at 12:58:45PM +0200, Felix Palmen wrote:
> * Dmitry Chagin  [20230830 13:48]:
> > On Wed, Aug 30, 2023 at 12:01:13PM +0200, Felix Palmen wrote:
> > > Unfortunately, install from GNU coreutils is now unable to install
> > > anything again. I tried both as 'nobody' and as 'root', it doesn't make
> > > a difference:
> > > [...]
> > > I assume the fsetxattr call needs some adjustment of error codes as well
> > > to make GNU tools play nice.
> > > 
> > 
> > I don't changed setxattr syscalls due to EPERM is a valid error from it,
> > however here's the essential difference between Linux and FreeBSD.
> > FreeBSD does not permits manipulatingg attributes in the
> > system namespace for unprivileged accounts.
> 
> Interesting! (and, a weird design ...)
> 
> > https://people.freebsd.org/~dchagin/xattr.patch
> 
> Yes, that's basically the same change I meanwhile did locally, except I
> restricted the adjustment to cases of writing the system namespace --
> not sure that's good for anything though.
> 
> In short: Works fine that way!
> 
Thanks, I see, I agree with your change, taken into account.

Re: Possible issue with linux xattr support?

* Felix Palmen  [20230830 12:58]:
> * Dmitry Chagin  [20230830 13:48]:
> > I don't changed setxattr syscalls due to EPERM is a valid error from it,
> > however here's the essential difference between Linux and FreeBSD.
> > FreeBSD does not permits manipulatingg attributes in the
> > system namespace for unprivileged accounts.
> 
> Interesting! (and, a weird design ...)

I meant the filesystem-specific policies of course. Quoting fail on my
side.

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

* Dmitry Chagin  [20230830 13:48]:
> On Wed, Aug 30, 2023 at 12:01:13PM +0200, Felix Palmen wrote:
> > Unfortunately, install from GNU coreutils is now unable to install
> > anything again. I tried both as 'nobody' and as 'root', it doesn't make
> > a difference:
> > [...]
> > I assume the fsetxattr call needs some adjustment of error codes as well
> > to make GNU tools play nice.
> > 
> 
> I don't changed setxattr syscalls due to EPERM is a valid error from it,
> however here's the essential difference between Linux and FreeBSD.
> FreeBSD does not permits manipulatingg attributes in the
> system namespace for unprivileged accounts.

Interesting! (and, a weird design ...)

> https://people.freebsd.org/~dchagin/xattr.patch

Yes, that's basically the same change I meanwhile did locally, except I
restricted the adjustment to cases of writing the system namespace --
not sure that's good for anything though.

In short: Works fine that way!

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

On Wed, Aug 30, 2023 at 12:33:23PM +0200, Felix Palmen wrote:
> * Felix Palmen  [20230830 12:01]:
> > Unfortunately, install from GNU coreutils is now unable to install
> > anything again. I tried both as 'nobody' and as 'root', it doesn't make
> > a difference:
> > [...]
> > I assume the fsetxattr call needs some adjustment of error codes as well
> > to make GNU tools play nice.
> 
> On a second thought, shouldn't it be two separate patches in the end?
> 
> * Some adjustment of the error codes seems to be needed to correctly
>   mimick Linux, so GNU tools et al don't misinterpret some error as
>   being "fatal"
> 
> * Optionally allowing access to the system namespace from within a jail
>   is also needed for some use cases (as shown by HBSD having a patch),
>   but is in fact unrelated to the issue with Linux *xattr calls
> 
> Please correct me if I'm wrong here ;)
>

sure, xattr.patch includes 5 commits

Re: Possible issue with linux xattr support?

* Felix Palmen  [20230830 12:01]:
> * Dmitry Chagin  [20230830 12:22]:
> > On Wed, Aug 30, 2023 at 11:20:39AM +0200, Felix Palmen wrote:
> > > * Unprivileged user will get ENOTSUP when trying to access the system
> > >   namespace (regardless of the new jail setting), so GNU tools like e.g.
> > >   coreutils install should "just work".
> > ENOTSUP or ENODATA (getxattr)
> 
> Unfortunately, install from GNU coreutils is now unable to install
> anything again. I tried both as 'nobody' and as 'root', it doesn't make
> a difference:

Sorry for the noise ... this little change fixes it for me:
https://people.freebsd.org/~zirias/patches/linux-setxattr.patch

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

On Wed, Aug 30, 2023 at 12:01:13PM +0200, Felix Palmen wrote:
> * Dmitry Chagin  [20230830 12:22]:
> > On Wed, Aug 30, 2023 at 11:20:39AM +0200, Felix Palmen wrote:
> > > * Unprivileged user will get ENOTSUP when trying to access the system
> > >   namespace (regardless of the new jail setting), so GNU tools like e.g.
> > >   coreutils install should "just work".
> > ENOTSUP or ENODATA (getxattr)
> 
> Unfortunately, install from GNU coreutils is now unable to install
> anything again. I tried both as 'nobody' and as 'root', it doesn't make
> a difference:
> 
> | # /compat/linux/usr/bin/install -c .libs/libexpat.so.1.8.10 
> /wrkdirs/usr/ports/textproc/linuxsrc-expat/work/stage/compat/linux/usr/lib64/libexpat.so.1.8.10
> | /compat/linux/usr/bin/install: setting permissions for 
> ‘/wrkdirs/usr/ports/textproc/linuxsrc-expat/work/stage/compat/linux/usr/lib64/libexpat.so.1.8.10’:
>  Operation not permitted
> 
> .. and truss shows this again:
> 
> | linux_fsetxattr(0x4,0x401860e8,0x134dd0,0x1c,0x0) ERR#-1 'Operation not 
> permitted'
> 
> This is without the new jail option. When I enable it, it still fails
> the same way as 'nobody' (which poudriere uses for building), but works
> fine as 'root'.
> 
> I assume the fsetxattr call needs some adjustment of error codes as well
> to make GNU tools play nice.
> 

I don't changed setxattr syscalls due to EPERM is a valid error from it,
however here's the essential difference between Linux and FreeBSD.
FreeBSD does not permits manipulatingg attributes in the
system namespace for unprivileged accounts. Well, we can return ENOTSUP
due to in Linux read and write access to system namespace depend on the
policy implemented for each filesystem, so we'll mimics we're a
filesystem that prohibits this for unprivelegd users.

https://people.freebsd.org/~dchagin/xattr.patch

Re: Possible issue with linux xattr support?

* Felix Palmen  [20230830 12:01]:
> Unfortunately, install from GNU coreutils is now unable to install
> anything again. I tried both as 'nobody' and as 'root', it doesn't make
> a difference:
> [...]
> I assume the fsetxattr call needs some adjustment of error codes as well
> to make GNU tools play nice.

On a second thought, shouldn't it be two separate patches in the end?

* Some adjustment of the error codes seems to be needed to correctly
  mimick Linux, so GNU tools et al don't misinterpret some error as
  being "fatal"

* Optionally allowing access to the system namespace from within a jail
  is also needed for some use cases (as shown by HBSD having a patch),
  but is in fact unrelated to the issue with Linux *xattr calls

Please correct me if I'm wrong here ;)

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

* Dmitry Chagin  [20230830 12:22]:
> On Wed, Aug 30, 2023 at 11:20:39AM +0200, Felix Palmen wrote:
> > * Unprivileged user will get ENOTSUP when trying to access the system
> >   namespace (regardless of the new jail setting), so GNU tools like e.g.
> >   coreutils install should "just work".
> ENOTSUP or ENODATA (getxattr)

Unfortunately, install from GNU coreutils is now unable to install
anything again. I tried both as 'nobody' and as 'root', it doesn't make
a difference:

| # /compat/linux/usr/bin/install -c .libs/libexpat.so.1.8.10 
/wrkdirs/usr/ports/textproc/linuxsrc-expat/work/stage/compat/linux/usr/lib64/libexpat.so.1.8.10
| /compat/linux/usr/bin/install: setting permissions for 
‘/wrkdirs/usr/ports/textproc/linuxsrc-expat/work/stage/compat/linux/usr/lib64/libexpat.so.1.8.10’:
 Operation not permitted

.. and truss shows this again:

| linux_fsetxattr(0x4,0x401860e8,0x134dd0,0x1c,0x0) ERR#-1 'Operation not 
permitted'

This is without the new jail option. When I enable it, it still fails
the same way as 'nobody' (which poudriere uses for building), but works
fine as 'root'.

I assume the fsetxattr call needs some adjustment of error codes as well
to make GNU tools play nice.

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

On Wed, Aug 30, 2023 at 11:20:39AM +0200, Felix Palmen wrote:
> * Dmitry Chagin  [20230830 11:57]:
> > On Tue, Aug 29, 2023 at 08:58:13PM +0200, Felix Palmen wrote:
> > > Thanks again for quickly fixing this! Can this still make 14.0-RELEASE?
> > > 
> > I think yes, thanks for testing, I revised the error handling and made
> > it more precise, can you test new patch in your environment.
> > 
> > https://people.freebsd.org/~dchagin/xattr.patch
> 
> Great, thanks! I see you now chose to add a jail option, certainly the
> cleanest solution.
> 
> Will test later today. Just to make sure I have the correct expectation
> about the behavior with the new patch applied:
> 
> * Unprivileged user will get ENOTSUP when trying to access the system
>   namespace (regardless of the new jail setting), so GNU tools like e.g.
>   coreutils install should "just work".
ENOTSUP or ENODATA (getxattr)

> * Root will get either ENOTSUP, or a fully working access to system.*
>   with the new jail setting enabled.
> 
> Are these assumptions correct?
> 
yes

Re: Possible issue with linux xattr support?

* Dmitry Chagin  [20230830 11:57]:
> On Tue, Aug 29, 2023 at 08:58:13PM +0200, Felix Palmen wrote:
> > Thanks again for quickly fixing this! Can this still make 14.0-RELEASE?
> > 
> I think yes, thanks for testing, I revised the error handling and made
> it more precise, can you test new patch in your environment.
> 
> https://people.freebsd.org/~dchagin/xattr.patch

Great, thanks! I see you now chose to add a jail option, certainly the
cleanest solution.

Will test later today. Just to make sure I have the correct expectation
about the behavior with the new patch applied:

* Unprivileged user will get ENOTSUP when trying to access the system
  namespace (regardless of the new jail setting), so GNU tools like e.g.
  coreutils install should "just work".
* Root will get either ENOTSUP, or a fully working access to system.*
  with the new jail setting enabled.

Are these assumptions correct?

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231

signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

On Tue, Aug 29, 2023 at 08:58:13PM +0200, Felix Palmen wrote:
> * Dmitry Chagin  [20230829 21:12]:
> > On Tue, Aug 29, 2023 at 07:02:22PM +0200, Felix Palmen wrote:
> > > So, using user.* works, using system.* doesn't, and maybe a bit
> > > surprising(?), dumping all attributes which by default excludes the
> > > system namespace doesn't work either.
> > > 
> > 
> > As expected, the second patch intended to allow access to system
> > namespace in jailed env.
> 
> Not exactly, according to the manual, 'getfattr -d' *excludes* the
> system namespace by default, so I would have expected it to work. But
> maybe that's an issue with the getfattr tool itself.
> 
> > > I still wonder, is the first patch needed anyways? Maybe I fail to
> > > understand something here. Won't it map *every* EPERM to ENOSUP and
> > > can't this be an issue?
> > > 
> > 
> > fine, thanks. Gnu tools running under unprivileged user will fail, eg
> > ls, which uses getfattr() to get the posix acl
> 
> Ah, I see, that would still break "Linux jails" then...
> 
> Thanks again for quickly fixing this! Can this still make 14.0-RELEASE?
> 
I think yes, thanks for testing, I revised the error handling and made
it more precise, can you test new patch in your environment.

https://people.freebsd.org/~dchagin/xattr.patch

Revert previous patches

Re: Possible issue with linux xattr support?

* Dmitry Chagin  [20230829 23:16]:
> On Tue, Aug 29, 2023 at 03:02:58PM -0400, Shawn Webb wrote:
> > Back in 2019, I had a similar issue: I needed access to be able to
> > read/write to the system extended attribute namespace from within a
> > jailed context. I wrote a rather simple patch that provides that
> > support on a per-jail basis:
> > 
> > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3
> > 
> > Hopefully that's useful to someone.
> > 
> 
> Nice, thank you. I'd prefer to disable it by default, like on a host.

When it's disabled by default, it will require additional configuration
to make "Linux jails" work again.

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

2023-08-29 Thread Alexander Leidinger

Am 2023-08-29 21:31, schrieb Felix Palmen:

* Shawn Webb  [20230829 15:25]:

On Tue, Aug 29, 2023 at 09:15:03PM +0200, Felix Palmen wrote:
> * Kyle Evans  [20230829 14:07]:
> > On 8/29/23 14:02, Shawn Webb wrote:
> > > Back in 2019, I had a similar issue: I needed access to be able to
> > > read/write to the system extended attribute namespace from within a
> > > jailed context. I wrote a rather simple patch that provides that
> > > support on a per-jail basis:
> > >
> > > 
https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3
> > >
> > > Hopefully that's useful to someone.
> > >
> > > Thanks,
> > >
> >
> > FWIW (which likely isn't much), I like this approach much better; it makes
> > more sense to me that it's a feature controlled by the creator of the jail
> > and not one allowed just by using a compat ABI within a jail.
>
> Well, a typical GNU userland won't work in a jail without this, that's
> what I know now. But I'm certainly with you, it doesn't feel logical
> that a Linux binary can do something in a jail a FreeBSD binary can't.
>
> So, indeed, making it a jail option sounds better.
>
> Unless, bringing back a question raised earlier in this thread: What's
> the reason to restrict this in a jailed context in the first place? IOW,
> could it just be allowed unconditionally?

In HardenedBSD's case, since we use filesystem extended attributes to
toggle exploit mitigations on a per-application basis, there's now a
conceptual security boundary between the host and the jail.

Should the jail and the host share resources, like executables, a
jailed process could toggle an exploit mitigation, and the toggle
would bubble up to the host. So the next time the host executed
/shared/app/executable/here, the security posture of the host would be
affected.

Isn't the sane approach here *not* to share any executables with a jail
other than via a read-only nullfs mount?

In https://reviews.freebsd.org/D40370 I provide infrastructure to 
automatically jail rc.d services. It will use the complete filesystem of 
the system, but uses all the other restrictions of jails. So the answer 
to your questions is "it depends".

Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF

Re: Possible issue with linux xattr support?

2023-08-29 Thread Alexander Leidinger


Am 2023-08-29 21:02, schrieb Shawn Webb:


Back in 2019, I had a similar issue: I needed access to be able to
read/write to the system extended attribute namespace from within a
jailed context. I wrote a rather simple patch that provides that
support on a per-jail basis:

https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3


You enabled it by default. I would assume you had a thought about the 
implications... any memories about it?


What I'm after is:
 - What can go wrong if we enable it by default?
 - Why would we like to disable it (or any ideas why it is disabled by 
default in FreeBSD)?


Depending in the answers we may even use a simpler patch and have it 
allowed in jails even without the possibility to configure it.


Bye,
Alexander.

--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.orgnetch...@freebsd.org  : PGP 0x8F31830F9F2772BF

Re: Possible issue with linux xattr support?

2023-08-29 Thread Kyle Evans

On 8/29/23 14:15, Felix Palmen wrote:

* Kyle Evans [20230829 14:07]:

On 8/29/23 14:02, Shawn Webb wrote:

Back in 2019, I had a similar issue: I needed access to be able to
read/write to the system extended attribute namespace from within a
jailed context. I wrote a rather simple patch that provides that
support on a per-jail basis:

https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3

Hopefully that's useful to someone.

Thanks,

FWIW (which likely isn't much), I like this approach much better; it makes
more sense to me that it's a feature controlled by the creator of the jail
and not one allowed just by using a compat ABI within a jail.

Well, a typical GNU userland won't work in a jail without this, that's
what I know now. But I'm certainly with you, it doesn't feel logical
that a Linux binary can do something in a jail a FreeBSD binary can't.

So, indeed, making it a jail option sounds better.

Unless, bringing back a question raised earlier in this thread: What's
the reason to restrict this in a jailed context in the first place? IOW,
could it just be allowed unconditionally?

I don't think we can answer this definitively, FreeBSD has a pretty wide
variety of users. I note that we don't /need/ to answer it, either, with
Shawn's patch; it defaults to system xattrs allowed and an individual
sysadmin can make that decision for their own context (and supporting
the knob is relatively low-cost).

The only part I'm not sure I agree with is the addition of the new flag
to PR_ALLOW_DIFFERENCES. That allows it to be disabled by system root
for jail "foo", but root in jail "foo" can create another jail "foo.bar"
in which it *is* enabled (rather than only allowing "foo.bar" to have it
enabled if its parent does). IMO the name PR_ALLOW_DIFFERENCES is a bit
off, because to me it would imply that it just allows the flag to be set
in one jail and unset in its child jail.

Thanks,

Kyle Evans

Re: Possible issue with linux xattr support?

2023-08-29 Thread Dmitry Chagin

On Tue, Aug 29, 2023 at 03:02:58PM -0400, Shawn Webb wrote:
> On Tue, Aug 29, 2023 at 05:45:51PM +0300, Dmitry Chagin wrote:
> > On Tue, Aug 29, 2023 at 12:59:11PM +0200, Felix Palmen wrote:
> > > * Dmitry Chagin  [20230828 18:57]:
> > > > On Mon, Aug 28, 2023 at 08:03:33AM +0200, Felix Palmen wrote:
> > > > > * Cy Schubert  [20230827 16:59]:
> > > > > > 
> > > > > > If we are to break it to fix a problem, maybe a sysctl to 
> > > > > > enable/disable then?
> > > > > 
> > > > > IMHO depends on the exact nature of the problem. If it's confirmed 
> > > > > that
> > > > > it (always and only) breaks for jailed processes, just disabling it 
> > > > > for
> > > > > them would be the better workaround. "No-op" calls won't break 
> > > > > anything.
> > > > > 
> > > > 
> > > > please, try: https://people.freebsd.org/~dchagin/xattrerror.patch
> > > 
> > > Thanks, I can confirm this avoids the issue in both cases I experienced
> > > (install from GNU coreutils and python).
> > > 
> > thanks, this is the first half of the fix, it works for you due to you
> > are running tools under unprivileged user, afaiu. The second I have
> > tested by myself :)
> > 
> > > If I understand this patch correctly, it completely avoids EPERM,
> > > masking it as not supported, so callers should consider it non-fatal,
> > > allowing to silently ignore writing of "system" attributes while still
> > > keeping other functionality?
> > > 
> > system namespace is accessible only for privileged user, for others Linux
> > returns ENOTSUP. So many tools ignores this error, eg ls.
> > 
> > the second: https://people.freebsd.org/~dchagin/sea_jailed.patch
> > 
> > Try this under privileged user, please.
> 
> Back in 2019, I had a similar issue: I needed access to be able to
> read/write to the system extended attribute namespace from within a
> jailed context. I wrote a rather simple patch that provides that
> support on a per-jail basis:
> 
> https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3
> 
> Hopefully that's useful to someone.
> 

Nice, thank you. I'd prefer to disable it by default, like on a host.

Re: Possible issue with linux xattr support?

2023-08-29 Thread Shawn Webb

On Tue, Aug 29, 2023 at 09:31:46PM +0200, Felix Palmen wrote:
> * Shawn Webb  [20230829 15:25]:
> > On Tue, Aug 29, 2023 at 09:15:03PM +0200, Felix Palmen wrote:
> > > * Kyle Evans  [20230829 14:07]:
> > > > On 8/29/23 14:02, Shawn Webb wrote:
> > > > > Back in 2019, I had a similar issue: I needed access to be able to
> > > > > read/write to the system extended attribute namespace from within a
> > > > > jailed context. I wrote a rather simple patch that provides that
> > > > > support on a per-jail basis:
> > > > > 
> > > > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3
> > > > > 
> > > > > Hopefully that's useful to someone.
> > > > > 
> > > > > Thanks,
> > > > > 
> > > > 
> > > > FWIW (which likely isn't much), I like this approach much better; it 
> > > > makes
> > > > more sense to me that it's a feature controlled by the creator of the 
> > > > jail
> > > > and not one allowed just by using a compat ABI within a jail.
> > > 
> > > Well, a typical GNU userland won't work in a jail without this, that's
> > > what I know now. But I'm certainly with you, it doesn't feel logical
> > > that a Linux binary can do something in a jail a FreeBSD binary can't.
> > > 
> > > So, indeed, making it a jail option sounds better.
> > > 
> > > Unless, bringing back a question raised earlier in this thread: What's
> > > the reason to restrict this in a jailed context in the first place? IOW,
> > > could it just be allowed unconditionally?
> > 
> > In HardenedBSD's case, since we use filesystem extended attributes to
> > toggle exploit mitigations on a per-application basis, there's now a
> > conceptual security boundary between the host and the jail.
> > 
> > Should the jail and the host share resources, like executables, a
> > jailed process could toggle an exploit mitigation, and the toggle
> > would bubble up to the host. So the next time the host executed
> > /shared/app/executable/here, the security posture of the host would be
> > affected.
> 
> Isn't the sane approach here *not* to share any executables with a jail
> other than via a read-only nullfs mount?

I thought about that, too, but nullfs is not guaranteed to be
available or applicable in all environments.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

* Shawn Webb  [20230829 15:25]:
> On Tue, Aug 29, 2023 at 09:15:03PM +0200, Felix Palmen wrote:
> > * Kyle Evans  [20230829 14:07]:
> > > On 8/29/23 14:02, Shawn Webb wrote:
> > > > Back in 2019, I had a similar issue: I needed access to be able to
> > > > read/write to the system extended attribute namespace from within a
> > > > jailed context. I wrote a rather simple patch that provides that
> > > > support on a per-jail basis:
> > > > 
> > > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3
> > > > 
> > > > Hopefully that's useful to someone.
> > > > 
> > > > Thanks,
> > > > 
> > > 
> > > FWIW (which likely isn't much), I like this approach much better; it makes
> > > more sense to me that it's a feature controlled by the creator of the jail
> > > and not one allowed just by using a compat ABI within a jail.
> > 
> > Well, a typical GNU userland won't work in a jail without this, that's
> > what I know now. But I'm certainly with you, it doesn't feel logical
> > that a Linux binary can do something in a jail a FreeBSD binary can't.
> > 
> > So, indeed, making it a jail option sounds better.
> > 
> > Unless, bringing back a question raised earlier in this thread: What's
> > the reason to restrict this in a jailed context in the first place? IOW,
> > could it just be allowed unconditionally?
> 
> In HardenedBSD's case, since we use filesystem extended attributes to
> toggle exploit mitigations on a per-application basis, there's now a
> conceptual security boundary between the host and the jail.
> 
> Should the jail and the host share resources, like executables, a
> jailed process could toggle an exploit mitigation, and the toggle
> would bubble up to the host. So the next time the host executed
> /shared/app/executable/here, the security posture of the host would be
> affected.

Isn't the sane approach here *not* to share any executables with a jail
other than via a read-only nullfs mount?

> FreeBSD uses ELF header tagging, not filesystem extended attributes,
> to toggle exploit mitigations. So my description above is moot for
> FreeBSD users. I'm just hoping to share a unique perspective.

Thanks!

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

2023-08-29 Thread Shawn Webb

On Tue, Aug 29, 2023 at 09:15:03PM +0200, Felix Palmen wrote:
> * Kyle Evans  [20230829 14:07]:
> > On 8/29/23 14:02, Shawn Webb wrote:
> > > Back in 2019, I had a similar issue: I needed access to be able to
> > > read/write to the system extended attribute namespace from within a
> > > jailed context. I wrote a rather simple patch that provides that
> > > support on a per-jail basis:
> > > 
> > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3
> > > 
> > > Hopefully that's useful to someone.
> > > 
> > > Thanks,
> > > 
> > 
> > FWIW (which likely isn't much), I like this approach much better; it makes
> > more sense to me that it's a feature controlled by the creator of the jail
> > and not one allowed just by using a compat ABI within a jail.
> 
> Well, a typical GNU userland won't work in a jail without this, that's
> what I know now. But I'm certainly with you, it doesn't feel logical
> that a Linux binary can do something in a jail a FreeBSD binary can't.
> 
> So, indeed, making it a jail option sounds better.
> 
> Unless, bringing back a question raised earlier in this thread: What's
> the reason to restrict this in a jailed context in the first place? IOW,
> could it just be allowed unconditionally?

In HardenedBSD's case, since we use filesystem extended attributes to
toggle exploit mitigations on a per-application basis, there's now a
conceptual security boundary between the host and the jail.

Should the jail and the host share resources, like executables, a
jailed process could toggle an exploit mitigation, and the toggle
would bubble up to the host. So the next time the host executed
/shared/app/executable/here, the security posture of the host would be
affected.

FreeBSD uses ELF header tagging, not filesystem extended attributes,
to toggle exploit mitigations. So my description above is moot for
FreeBSD users. I'm just hoping to share a unique perspective.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc

signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

* Kyle Evans  [20230829 14:07]:
> On 8/29/23 14:02, Shawn Webb wrote:
> > Back in 2019, I had a similar issue: I needed access to be able to
> > read/write to the system extended attribute namespace from within a
> > jailed context. I wrote a rather simple patch that provides that
> > support on a per-jail basis:
> > 
> > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3
> > 
> > Hopefully that's useful to someone.
> > 
> > Thanks,
> > 
> 
> FWIW (which likely isn't much), I like this approach much better; it makes
> more sense to me that it's a feature controlled by the creator of the jail
> and not one allowed just by using a compat ABI within a jail.

Well, a typical GNU userland won't work in a jail without this, that's
what I know now. But I'm certainly with you, it doesn't feel logical
that a Linux binary can do something in a jail a FreeBSD binary can't.

So, indeed, making it a jail option sounds better.

Unless, bringing back a question raised earlier in this thread: What's
the reason to restrict this in a jailed context in the first place? IOW,
could it just be allowed unconditionally?

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231

signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

2023-08-29 Thread Kyle Evans

On 8/29/23 14:02, Shawn Webb wrote:

On Tue, Aug 29, 2023 at 05:45:51PM +0300, Dmitry Chagin wrote:

On Tue, Aug 29, 2023 at 12:59:11PM +0200, Felix Palmen wrote:

* Dmitry Chagin [20230828 18:57]:

On Mon, Aug 28, 2023 at 08:03:33AM +0200, Felix Palmen wrote:

* Cy Schubert [20230827 16:59]:

If we are to break it to fix a problem, maybe a sysctl to enable/disable then?

IMHO depends on the exact nature of the problem. If it's confirmed that
it (always and only) breaks for jailed processes, just disabling it for
them would be the better workaround. "No-op" calls won't break anything.

please, try: https://people.freebsd.org/~dchagin/xattrerror.patch

Thanks, I can confirm this avoids the issue in both cases I experienced
(install from GNU coreutils and python).

thanks, this is the first half of the fix, it works for you due to you
are running tools under unprivileged user, afaiu. The second I have
tested by myself :)

If I understand this patch correctly, it completely avoids EPERM,
masking it as not supported, so callers should consider it non-fatal,
allowing to silently ignore writing of "system" attributes while still
keeping other functionality?

system namespace is accessible only for privileged user, for others Linux
returns ENOTSUP. So many tools ignores this error, eg ls.

the second: https://people.freebsd.org/~dchagin/sea_jailed.patch

Try this under privileged user, please.

https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3

Hopefully that's useful to someone.

Thanks,

FWIW (which likely isn't much), I like this approach much better; it
makes more sense to me that it's a feature controlled by the creator of
the jail and not one allowed just by using a compat ABI within a jail.

Thanks,

Kyle Evans

Re: Possible issue with linux xattr support?

2023-08-29 Thread Shawn Webb

On Tue, Aug 29, 2023 at 05:45:51PM +0300, Dmitry Chagin wrote:
> On Tue, Aug 29, 2023 at 12:59:11PM +0200, Felix Palmen wrote:
> > * Dmitry Chagin  [20230828 18:57]:
> > > On Mon, Aug 28, 2023 at 08:03:33AM +0200, Felix Palmen wrote:
> > > > * Cy Schubert  [20230827 16:59]:
> > > > > 
> > > > > If we are to break it to fix a problem, maybe a sysctl to 
> > > > > enable/disable then?
> > > > 
> > > > IMHO depends on the exact nature of the problem. If it's confirmed that
> > > > it (always and only) breaks for jailed processes, just disabling it for
> > > > them would be the better workaround. "No-op" calls won't break anything.
> > > > 
> > > 
> > > please, try: https://people.freebsd.org/~dchagin/xattrerror.patch
> > 
> > Thanks, I can confirm this avoids the issue in both cases I experienced
> > (install from GNU coreutils and python).
> > 
> thanks, this is the first half of the fix, it works for you due to you
> are running tools under unprivileged user, afaiu. The second I have
> tested by myself :)
> 
> > If I understand this patch correctly, it completely avoids EPERM,
> > masking it as not supported, so callers should consider it non-fatal,
> > allowing to silently ignore writing of "system" attributes while still
> > keeping other functionality?
> > 
> system namespace is accessible only for privileged user, for others Linux
> returns ENOTSUP. So many tools ignores this error, eg ls.
> 
> the second: https://people.freebsd.org/~dchagin/sea_jailed.patch
> 
> Try this under privileged user, please.

Back in 2019, I had a similar issue: I needed access to be able to
read/write to the system extended attribute namespace from within a
jailed context. I wrote a rather simple patch that provides that
support on a per-jail basis:

https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/commit/96c85982b45e44a6105664c7068a92d0a61da2a3

Hopefully that's useful to someone.

Thanks,

-- 
Shawn Webb
Cofounder / Security Engineer
HardenedBSD

https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

* Dmitry Chagin  [20230829 21:12]:
> On Tue, Aug 29, 2023 at 07:02:22PM +0200, Felix Palmen wrote:
> > So, using user.* works, using system.* doesn't, and maybe a bit
> > surprising(?), dumping all attributes which by default excludes the
> > system namespace doesn't work either.
> > 
> 
> As expected, the second patch intended to allow access to system
> namespace in jailed env.

Not exactly, according to the manual, 'getfattr -d' *excludes* the
system namespace by default, so I would have expected it to work. But
maybe that's an issue with the getfattr tool itself.

> > I still wonder, is the first patch needed anyways? Maybe I fail to
> > understand something here. Won't it map *every* EPERM to ENOSUP and
> > can't this be an issue?
> > 
> 
> fine, thanks. Gnu tools running under unprivileged user will fail, eg
> ls, which uses getfattr() to get the posix acl

Ah, I see, that would still break "Linux jails" then...

Thanks again for quickly fixing this! Can this still make 14.0-RELEASE?

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

2023-08-29 Thread Dmitry Chagin

On Tue, Aug 29, 2023 at 07:02:22PM +0200, Felix Palmen wrote:
> * Dmitry Chagin  [20230829 17:45]:
> > On Tue, Aug 29, 2023 at 12:59:11PM +0200, Felix Palmen wrote:
> > > Thanks, I can confirm this avoids the issue in both cases I experienced
> > > (install from GNU coreutils and python).
> > > 
> > thanks, this is the first half of the fix, it works for you due to you
> > are running tools under unprivileged user, afaiu. The second I have
> > tested by myself :)
> 
> Sure, poudriere is running all builds as "nobody" by default.
> 
> > > If I understand this patch correctly, it completely avoids EPERM,
> > > masking it as not supported, so callers should consider it non-fatal,
> > > allowing to silently ignore writing of "system" attributes while still
> > > keeping other functionality?
> > > 
> > system namespace is accessible only for privileged user, for others Linux
> > returns ENOTSUP. So many tools ignores this error, eg ls.
> > 
> > the second: https://people.freebsd.org/~dchagin/sea_jailed.patch
> 
> Ok, I did some tests in a poudriere jail using Linux bash, as root.
> First, with only the first patch:
> 
> | bash-5.2# getfattr -d /bin/sh
> | getfattr: /bin/sh: Operation not supported
> | bash-5.2# setfattr -n user.foo -v bar /bin/sh
> | bash-5.2# getfattr -n user.foo /bin/sh
> | getfattr: Removing leading '/' from absolute path names
> | # file: bin/sh
> | user.foo="bar"
> | bash-5.2# setfattr -x user.foo /bin/sh
> | bash-5.2# setfattr -x system.foo /bin/sh
> | setfattr: /bin/sh: Operation not supported
> 
> So, using user.* works, using system.* doesn't, and maybe a bit
> surprising(?), dumping all attributes which by default excludes the
> system namespace doesn't work either.
> 

As expected, the second patch intended to allow access to system
namespace in jailed env.

> Then with the second patch applied as well:
> 
> | bash-5.2# getfattr -d /bin/sh
> | bash-5.2# setfattr -n system.foo -v bar /bin/sh
> | bash-5.2# getfattr -d /bin/sh -m-
> | getfattr: Removing leading '/' from absolute path names
> | # file: bin/sh
> | system.foo="bar"
> | 
> | bash-5.2# setfattr -x system.foo /bin/sh
> | bash-5.2# getfattr -d /bin/sh -m-
> | bash-5.2#
> 
> This looks perfectly fine, thanks a lot!
> 
> I still wonder, is the first patch needed anyways? Maybe I fail to
> understand something here. Won't it map *every* EPERM to ENOSUP and
> can't this be an issue?
> 

fine, thanks. Gnu tools running under unprivileged user will fail, eg
ls, which uses getfattr() to get the posix acl

> Cheers, Felix
> 
> -- 
>  Felix Palmen  {private}   fe...@palmen-it.de
>  -- ports committer -- {web}  http://palmen-it.de
>  {pgp public key}  http://palmen-it.de/pub.txt
>  {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231

Re: Possible issue with linux xattr support?

* Dmitry Chagin  [20230829 17:45]:
> On Tue, Aug 29, 2023 at 12:59:11PM +0200, Felix Palmen wrote:
> > Thanks, I can confirm this avoids the issue in both cases I experienced
> > (install from GNU coreutils and python).
> > 
> thanks, this is the first half of the fix, it works for you due to you
> are running tools under unprivileged user, afaiu. The second I have
> tested by myself :)

Sure, poudriere is running all builds as "nobody" by default.

> > If I understand this patch correctly, it completely avoids EPERM,
> > masking it as not supported, so callers should consider it non-fatal,
> > allowing to silently ignore writing of "system" attributes while still
> > keeping other functionality?
> > 
> system namespace is accessible only for privileged user, for others Linux
> returns ENOTSUP. So many tools ignores this error, eg ls.
> 
> the second: https://people.freebsd.org/~dchagin/sea_jailed.patch

Ok, I did some tests in a poudriere jail using Linux bash, as root.
First, with only the first patch:

| bash-5.2# getfattr -d /bin/sh
| getfattr: /bin/sh: Operation not supported
| bash-5.2# setfattr -n user.foo -v bar /bin/sh
| bash-5.2# getfattr -n user.foo /bin/sh
| getfattr: Removing leading '/' from absolute path names
| # file: bin/sh
| user.foo="bar"
| bash-5.2# setfattr -x user.foo /bin/sh
| bash-5.2# setfattr -x system.foo /bin/sh
| setfattr: /bin/sh: Operation not supported

So, using user.* works, using system.* doesn't, and maybe a bit
surprising(?), dumping all attributes which by default excludes the
system namespace doesn't work either.

Then with the second patch applied as well:

| bash-5.2# getfattr -d /bin/sh
| bash-5.2# setfattr -n system.foo -v bar /bin/sh
| bash-5.2# getfattr -d /bin/sh -m-
| getfattr: Removing leading '/' from absolute path names
| # file: bin/sh
| system.foo="bar"
| 
| bash-5.2# setfattr -x system.foo /bin/sh
| bash-5.2# getfattr -d /bin/sh -m-
| bash-5.2#

This looks perfectly fine, thanks a lot!

I still wonder, is the first patch needed anyways? Maybe I fail to
understand something here. Won't it map *every* EPERM to ENOSUP and
can't this be an issue?

Cheers, Felix

-- 
 Felix Palmen  {private}   fe...@palmen-it.de
 -- ports committer -- {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231


signature.asc
Description: PGP signature

Re: Possible issue with linux xattr support?

2023-08-29 Thread Dmitry Chagin

On Tue, Aug 29, 2023 at 12:59:11PM +0200, Felix Palmen wrote:
> * Dmitry Chagin  [20230828 18:57]:
> > On Mon, Aug 28, 2023 at 08:03:33AM +0200, Felix Palmen wrote:
> > > * Cy Schubert  [20230827 16:59]:
> > > > 
> > > > If we are to break it to fix a problem, maybe a sysctl to 
> > > > enable/disable then?
> > > 
> > > IMHO depends on the exact nature of the problem. If it's confirmed that
> > > it (always and only) breaks for jailed processes, just disabling it for
> > > them would be the better workaround. "No-op" calls won't break anything.
> > > 
> > 
> > please, try: https://people.freebsd.org/~dchagin/xattrerror.patch
> 
> Thanks, I can confirm this avoids the issue in both cases I experienced
> (install from GNU coreutils and python).
> 
thanks, this is the first half of the fix, it works for you due to you
are running tools under unprivileged user, afaiu. The second I have
tested by myself :)

> If I understand this patch correctly, it completely avoids EPERM,
> masking it as not supported, so callers should consider it non-fatal,
> allowing to silently ignore writing of "system" attributes while still
> keeping other functionality?
> 
system namespace is accessible only for privileged user, for others Linux
returns ENOTSUP. So many tools ignores this error, eg ls.

the second: https://people.freebsd.org/~dchagin/sea_jailed.patch

Try this under privileged user, please.

> I wonder whether this could cause trouble in other scenarios (like a
> read-only fs or actually missing file permissions)?
> 
> Cheers, Felix
> 
> -- 
>  Felix Palmen  {private}   fe...@palmen-it.de
>  -- ports committer -- {web}  http://palmen-it.de
>  {pgp public key}  http://palmen-it.de/pub.txt
>  {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231

Re: Possible issue with linux xattr support?