| 1 |
On 06/14/14 06:49, PaX Team wrote: |
| 2 |
> On 13 Jun 2014 at 16:40, subscryer@×××××.com wrote: |
| 3 |
> |
| 4 |
>> I suggest a little improvement to the wiki: state the fact that |
| 5 |
>> user_xattr must be enabled in fstab for the relevant filesystems (at |
| 6 |
>> least /) as this isn't default AFAIK. |
| 7 |
> |
| 8 |
> i already forcibly enable the general xattr support in filesystems in |
| 9 |
> the kernel .config when the xattr based control method is enabled, i |
| 10 |
> could also forcibly enable user xattrs on actual mounts. the question |
| 11 |
> is whether such a policy decision belongs in the kernel or not... |
| 12 |
> |
| 13 |
|
| 14 |
I was going to say "no this doesn't belong in the kernel" but actually |
| 15 |
yeah, maybe it does. If we are going to enable xattr support on |
| 16 |
filesystems when we want XATTR_PAX, then we should enable user.* xattr |
| 17 |
support on mounts. The other xattr namespaces are already enabled on |
| 18 |
those filesystems, so why not add user.*? One caveat I can think of is |
| 19 |
we only need user.pax.flags while we'd be turning on all of user.* so |
| 20 |
maybe some perverse attack could make use of user.exploitme or something |
| 21 |
like that? (I'm stretching it, I know.) Also we'd be removing the |
| 22 |
choice to mount nouser_xattr and effectively force all markings off. Or |
| 23 |
you could just change the default behavior of mount to mount -o |
| 24 |
user_xattr and the user would then have to mount -o nouser_xattr to turn |
| 25 |
user.* off. |
| 26 |
|
| 27 |
Comments? |
| 28 |
|
| 29 |
-- |
| 30 |
Anthony G. Basile, Ph. D. |
| 31 |
Chair of Information Technology |
| 32 |
D'Youville College |
| 33 |
Buffalo, NY 14201 |
| 34 |
(716) 829-8197 |
Archives