Apologies for the late reply. On Sat, Feb 7, 2015 at 8:52 AM, <Valdis.Kletnieks@vt.edu> wrote:
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.
You are correct. I missed out on that fact. Well, there's still a workaround. I will put in some kind of data in the security structure of task_struct as soon as it is created.
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?)
I am planning to create a new system call for that and I am not sure how that would be insecure. Please correct me if I am wrong. What you're saying is definitely simpler than my approach but it probably violates some POSIX standards(including chdir in chroot) which I don't want to. Also, I aim for my tool to be just a simple addendum to the traditional system call rather than adding a completely new call to handle the entire process.