new syscall: flink
Once a process unlinks the last directory entry referencing a particular inode that it has an
open fd for and then passes the open fd to some other process (regardless of exactly how it does that), it seems to me that it has conceded any interest in the previous security constraints associated with that inode or with the recently unlinked last directory entry for it. If the client process subsequently flink()s to the inode, it is merely a zerocopy file copy.
Since the client owns the new directory entry, it can chmod the inode to have any permissions it wants, create or modify an ACL where ACLs are in use, modify a capabilities mask more fine-grained than traditional unix permissions if something like that is in use, etc.
The cases with potential security implications are all in the context of flink()ing to an open fd for an inode that still corresponds to at least one directory entry.
Regards,
Clayton Weaver
<mailto: [email protected]>
Signature · 3 lines
_______________________________________________ Sign-up for your own FREE Personalized E-mail at Mail.com http://www.mail.com/?sr=signup
Quoted 1 line · Clayton Weaver
The cases with potential security implications are all in the context of flink()ing to an open fd for an inode that still corresponds to at least one directory entry.
almost.
there is of course always the case of a setuid app doing a userspace ACL like thing and only sending fd's to non-privileged apps based on some security scheme..... flink() would sort of break this thing entirely
Quoted 7 lines · Clayton Weaver
Once a process unlinks the last directory entry referencing a particular inode that it has an
open fd for and then passes the open fd to some other process (regardless of exactly how it does that), it seems to me that it has conceded any interest in the previous security constraints associated with that inode or with the recently
unlinked last directory entry for it.
Huh? That's not the Unix model. If I pass you a read-only file descriptor, you're not supposed to be able to get write access to the fd. If you can, that's a security hole. This is true whether the fd refers to an inode still linked into the filesystem or not.
Quoted 3 lines
The cases with potential security implications are all in the context of flink()ing to an open fd for an inode that still corresponds to at least one directory entry.
No, that's not correct.
Quoted 2 lines · Clayton Weaver
If the client process subsequently flink()s to the inode, it is merely a zerocopy file copy.
As far as access to the data is concerned, yes. But there's also the location of the file. E.g. this might enable you to fill somebody else's quota, or, if distinct physical devices can be be covered by the same file system, to access a physical device that would otherwise not be available to you.
Example: I write some kind of RAID mounted at /world, that contains my disk under /world/disk, and some Flash storage under /world/flash. I protect /world/flash against writes by other people. If a read-only FD could be turned into something writeable, some malicious creature could "wear out" my Flash by writing to it a lot of times.
- Werner
Signature · 3 lines
_________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina [email protected] / /_http://www.almesberger.net/____________________________________________/
Followup to: <[email protected]> By author: "Clayton Weaver" <[email protected]> In newsgroup: linux.dev.kernel
Quoted 7 lines
Since the client owns the new directory entry, it can chmod the inode to have any permissions it wants, create or modify an ACL where ACLs are in use, modify a capabilities mask more fine-grained than traditional unix permissions if something like that is in use, etc.
Uhm, no. Ownership is an inode property.
-hpa
Signature · 3 lines
<[email protected]> at work, <[email protected]> in private! "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
Quoted 5 lines · I wrote:
Example: I write some kind of RAID mounted at /world, that contains my disk under /world/disk, and some Flash storage under /world/flash. I protect /world/flash against writes by other people. If a read-only FD could be turned into something writeable, some malicious creature could "wear out" my Flash by writing to it a lot of times.
Just to clarify: the file in question would be inaccessible for the abuser, and the read-only fd would have to be handed out by some access mediator.
Obviously, if the abuser obtains a read-only fd directly by opening a file, the hypothetical flink couldn't be used for privilege escalation.
- Werner
Signature · 3 lines
_________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina [email protected] / /_http://www.almesberger.net/____________________________________________/