Hi Anand,
On Tue, Feb 07, 2017 at 01:55:03PM +0800, Anand Jain wrote:
>
> These reasons would equally apply to ioctl interface as well.
> I don't see this being limiting factor for not using set/getfattr.
>
> Again. I don't see these as the limiting factor for not using
> set/getfattr. And about the iv/nonce you mentioned, I didn't
> say to set IV/nonce value from the user land, but it could have
> been done the same way the attribute inheritance is working now
> with in the fs/crypto kernel.
>
> BTRFS does not have ioctl for the crypto policy set, it did it
> through xattr, I would like to retain that part even when fs/crypto
> is used, unless there is any security reason. (But definitely not at
> the cost of being incompatible with rest of the FSs, I hope to fix
> that part as well).
>
>
> Here, I am just trying to ensure not to over-do in the name of
> security.
> And by letting encryption meta-data easily usable through extended
> attributes I hope to encourage tools to leverage on the FS encryption.
>
>
> Still my question is unanswered, I was specific to any security
> or other reasons that set/getfattr interface wasn't used to
> read/write the policy information. And also why SElinux attributes
> instead of normal extended attributes.
>
I think you're partially correct because setxattr() and getxattr() can actually
do more than just setting/getting the on-disk bytes, depending on what xattr
handers the filesystem provides. (I had assumed you were referring to
"non-magic" xattrs, like the ones in the "user." namespace.) For example, many
filesystems have a handler for the POSIX ACL extended attributes
("system.posix_acl_access" and "system.posix_acl_default"), and these have
special behavior. BTRFS also provides a handler for the "btrfs." namespace and
allows setting/getting "btrfs.compression", also with special behavior.
This could have been done for the fscrypt API, I think, provided that an
extended attribute in the "system." namespace, or in a dedicated namespace like
"fscrypt.", was used. This would have allow taking advantage of the setxattr()
infrastructure and may have helped prevent some of the bugs I've had to fix in
FS_IOC_SET_ENCRYPTION_POLICY.
However, the issue which I was getting at is that encryption might just diverge
from the standard xattr interface too much for it to be appropriate. For
example you would not be able to use removexattr() to remove the encryption
xattr. Nor would the "replace" semantics of setxattr() work. Nor would
'getfattr --dump' and 'setfattr --restore' work, because the encryption xattrs
would be included in the xattr dump but would not, in general, be possible to
restore. Also, if the API requires a binary structure, then you kind of need a
custom program to use it anyway, and in that situation an ioctl() is just as
easy (if not easier) to use.
Anyway, if your intent is to change the fscrypt API, note that this almost
certainly can't be done because people are already using it. It would however
be technically possible to add a new API and deprecate the old one, if there was
a strong reason that made it worthwhile. Right now I am not convinced that
switching to an xattr interface is a good enough reason.
As for why fscrypt uses "SELinux attributes", it doesn't. The xattrs have a
special name which does not collide with any public namespace.
(Also note that I was not personally involved in the original design of the
fscrypt API at all, so others may know more than me about the design decisions.)
Eric
