Apologies for the late reply. On Sat, Feb 7, 2015 at 8:52 AM, <Valdis.Kletnieks@xxxxxx> 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. _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
