Jamie Lokier wrote:
> Casey Schaufler wrote:
>
>> Now I have a file that can have a thousand inodes, each of
>> which might have a different set of access control characteristics.
>>
>
> >From a security perspective, how is this different from a
> thousand separate files?
>
> The copy-on-write is just an optimisation, a filesystem implementation
> detail, from a certain perspective.
>
Yes, I understand that. It's entirely possible that I don't
actually have a valid concern, but I'm having a little trouble
convincing myself that all the bases are covered.
It's different from 1000 separate files because I can now have
one set of data blocks with read access controlled by 1000 different
users.
# chown user000 rfile000
...
# chown user999 rfile999
now 1000 different users can grant access to those blocks,
so long as they don't change. Without reflink() I know that if
I own the file, it isn't open (fuser says so) and it is mode 700
that noone else can read it sans privilege. With reflink() not
only is this not true, but I can't find out who might be able to
read it. Changing the permissions, ACL, SELinux label, Smack label,
or TOMOYO policy won't help, because there may be another inode
out there somewhere that I can't even access that is granting the
rest of the world access.
>> With a single inode there is a definitive
>> name for the file system object (device/inode) where with multiple
>> inodes there is not.
>>
>
> That's because there isn't a single object to name. Why do you want
> to pretend they are the same object?
>
Until they actually diverge you can't say which object the data
blocks belong to. That means you can't say which set of access
control information protects the information, because someone
needs access through one or the other but in either case is
looking at the same data.
> They are separate files which share some disk blocks to save space and
> time that's all. A low-level implementation detail. Completely
> separate files can share blocks like that too on some filesystems.
>
> In what way do the shared data blocks between otherwise separate files
> have any security implication?
>
> (Ok, ok, timing, ENOSPC, covert communications, but independent files
> can trigger such interactions too.)
>
> There's the actual creation of reflinks being invisible to i_nlink
> watchers yet not requiring read permission, which is new. But that
> has nothing to do with the shared data: it would have the same
> security implication even if reflink was just an ordinary file copy
> with its proposed permission check! :-)
>
Yeah, I can see the argument, I'm just not sure that I could
turn around and sell it to an eager-puppy security evaluator
fresh out of a PHD program at the U of Maryland.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
