Fwd: Fwd: Getting path in inode_permission

[noyb noybee]

Apologies for the late reply.

On Sat, Feb 7, 2015 at 8:52 AM,  <Valdis.Kletnieks at 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.