Fwd: Getting path in inode_permission
On Sat, Feb 7, 2015 at 4:21 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Sat, 07 Feb 2015 01:57:44 +0530, noyb noybee said:
I need the path lookup data as I need to specifically block inode loopkups originating from a certain path
Then just make sure the inodes you don't want accessed aren't in the namespace.
Hint: "from a certain path" is almost guaranteed to be a security hole, because all the attacker has to do is cwd() to some different path. And there's ../ games that can be played, and so on.
So what are you trying to protect by blocking some lookups? What's the threat model here?
I am trying to enhance the security features of the chroot "jail"(I know it wasn't built for the purpose). I am trying to prevent access to files outside the "jail" unless they specify a specific passsphrase. Whenever an inode is accessed, inode_persmission is called. I get the pid of the calling process by current->pid in the hook and check if it is a child of the original process for which chroot was run. If yes + if this process hasn't specified a passphrase + the path of the inode shows that it is outside the "jail", the request is blocked. I am also blocking all mounts in the "jail". Regards, winged_elite.
On Sat, 07 Feb 2015 07:27:13 +0530, noyb noybee said:
I am trying to enhance the security features of the chroot "jail"(I know it wasn't built for the purpose). I am trying to prevent access to files outside the "jail" unless they specify a specific
The right thing to do is design the jail so it *never* references files outside.
passsphrase. Whenever an inode is accessed, inode_persmission is called. I get the pid of the calling process by current->pid in the hook and check if it is a child of the original process for which
Bzzt! Wrong. Trivially beatable - all I have to do is double-fork, exit the child process, the grandchild gets reparented to PID 1, and your check fails.
chroot was run. If yes + if this process hasn't specified a passphrase + the path of the inode shows that it is outside the "jail", the request is blocked. I am also blocking all mounts in the "jail".
Plus the whole passphrase thing is probably equally easy to defeat. (Hint - how does the passphrase get passed to the kernel in the first place?)
participants (2)
-
noyb noybee -
Valdis.Kletnieks＠vt.edu