Getting path in inode_permission

Getting path in inode_permission

[noyb noybee]

I need the path lookup data as I need to specifically block inode
loopkups originating from a certain path(hence the permission mask is
not enough). Is there a way to get it from inside the inode_permission
hook or is there another hook I can use(not file_permission since
I want the hook for any kind of access, not just read/writes) ?


Regards,
winged_elite

Getting path in inode_permission

[Valdis.Kletnieks at vt.edu]

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150206/7a17423b/attachment.bin 

Fwd: Getting path in inode_permission

[noyb noybee]

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.

Fwd: Getting path in inode_permission

[Valdis.Kletnieks at vt.edu]

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?)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150206/fb2a0caa/attachment.bin 

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@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.

Fwd: Fwd: Getting path in inode_permission

[Valdis.Kletnieks at vt.edu]

On Wed, 11 Feb 2015 03:42:50 +0530, noyb noybee said:
> Apologies for the late reply.
>

> > 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.

You missed the point.  How does the process *securely* get the passphrase
that will be passed into the syscall? (Hint - a keystroke logger is only
the *start* of your problems.  Think about why the kernel module signing
code uses public-key crypto instead of symmetric private keys...)

> 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.

The problem with "simple addendum" is that it's *really* hard to get it right.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150210/74e85841/attachment.bin 

Fwd: Fwd: Getting path in inode_permission

[noyb noybee]

On Wed, Feb 11, 2015 at 4:29 AM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Wed, 11 Feb 2015 03:42:50 +0530, noyb noybee said:
> You missed the point.  How does the process *securely* get the passphrase
> that will be passed into the syscall? (Hint - a keystroke logger is only
> the *start* of your problems.  Think about why the kernel module signing
> code uses public-key crypto instead of symmetric private keys...)

I was planning that the calling process would call the new system call
which would return a pseudo-random key that is used as the
pass-phrase.

Fwd: Fwd: Getting path in inode_permission

[Valdis.Kletnieks at vt.edu]

On Thu, 12 Feb 2015 00:31:45 +0530, noyb noybee said:

> I was planning that the calling process would call the new system call
> which would return a pseudo-random key that is used as the
> pass-phrase.

So what prevents malicious code from doing a fork and then calling the
new syscall to get its own pseudo-random key to use as a passphrase?

Like I said, this is a lot harder to make secure than it looks.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150211/b254cf22/attachment.bin 

Fwd: Fwd: Getting path in inode_permission

[noyb noybee]

On Thu, Feb 12, 2015 at 2:07 AM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Thu, 12 Feb 2015 00:31:45 +0530, noyb noybee said:
>
>> I was planning that the calling process would call the new system call
>> which would return a pseudo-random key that is used as the
>> pass-phrase.
>
> So what prevents malicious code from doing a fork and then calling the
> new syscall to get its own pseudo-random key to use as a passphrase?
Well, any program which has root credentials is still allowed to call
chroot(it needs to get a new passphrase before) but not any program
with root credentials can exit it. The passphrase last generated(and
still unused) will be used as the passphrase for a chroot system
call(both needed to be called by the same processes, ofc). Once a
passphrase is used for a chroot system call, it is never
returned(pseudo-random) again.

Fwd: Fwd: Getting path in inode_permission

[Valdis.Kletnieks at vt.edu]

On Thu, 12 Feb 2015 03:19:46 +0530, noyb noybee said:

> Well, any program which has root credentials is still allowed to call
> chroot(it needs to get a new passphrase before) but not any program
> with root credentials can exit it.

Well see... now you have a problem.

If you don't allow that chroot program to fork() or exec(), you now have
the passphrase sitting in memory someplace (since you need to pass it back),
and exploit code can find it in memory.

If you allow fork/exec into other programs, it gets worse - now you need to
pass that passphrase to children.

And if you're using the passphrase for the chroot() call *itself*, you
have an even bigger problem - whatever access that passphrase adds is now
available *anywhere inside the chroot*.

So all I need to do is find a way to exploit the chroot, and now I have
access to resources outside the chroot.  At which point your security
scheme is *totally* broken.

Instead of your original:

> I am trying to prevent access to files outside the "jail" unless they specify
> a specific passsphrase.

You've just handed unfettered access to the files to the exploit.

How about you concentrate on "how were they able to access files outside
the chroot in the first place"?

> Once a passphrase is used for a chroot system call, it is never
> returned(pseudo-random) again.

Or so you hope. :)

It's easy to design security schemes that work if code follows the rules.
The fun is designing code that withstands attempts to break the rules.
Consider abuse of inherited file descriptors - say stderr is open to a
logfile.  My exploit code closes fd 2.  What happens the next time somebody
opens a file, and then something does fprintf(stderr,....)?

What happens if code trawls the process image and finds the magic key?

What happens if somebody forks? Or double/triple forks?

What happens if somebody sets LD_PRELOAD and then causes an exec()?

What happens if somebody manages to attach a child process to your process
and then triggers an unexpected SIGCHLD?  (Hint - it's *trivial* to actually
do that - see if you can guess how before reading the link below...)

Henry Spencer, a long time ago, wrote a good set of things to worry about when
writing set-UID programs - most of which also apply to chroot code.  Note that
this is *not* a complete list, it's *just* the low-hanging fruit.

http://www.daemon-systems.org/man/setuid.7.html

Now, can you explain what problem you're trying to solve with this security
scheme?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150211/0b3bf77f/attachment-0001.bin 

Fwd: Fwd: Getting path in inode_permission

[noyb noybee]

On Thu, Feb 12, 2015 at 3:44 AM,  <Valdis.Kletnieks@vt.edu> wrote:
> And if you're using the passphrase for the chroot() call *itself*, you
> have an even bigger problem - whatever access that passphrase adds is now
> available *anywhere inside the chroot*.
>
> So all I need to do is find a way to exploit the chroot, and now I have
> access to resources outside the chroot.  At which point your security
> scheme is *totally* broken.

You are right. Even on adding the passphrase, if the original program
that executed chroot is exploitable(which my solution tried to take
into account), it could still access the passphrase and we would be
back at square one.

> How about you concentrate on "how were they able to access files outside
> the chroot in the first place"?
So, closing all open file descriptors that are outside the new root
directory + changing the CWD + blocking any mounts.

Fwd: Fwd: Getting path in inode_permission

[Valdis.Kletnieks at vt.edu]

On Thu, 12 Feb 2015 23:41:18 +0530, noyb noybee said:
> On Thu, Feb 12, 2015 at 3:44 AM,  <Valdis.Kletnieks@vt.edu> wrote:

> > How about you concentrate on "how were they able to access files outside
> > the chroot in the first place"?
> So, closing all open file descriptors that are outside the new root
> directory + changing the CWD + blocking any mounts.

That's a good start.

Now, for bonus points - explain why you wanted something inside a chroot
to be able to access something outside the chroot.

(Hint - why can't you just bind-mount it into the chroot hierarchy before
launching the chroot'ed program?)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150212/06b8b7ef/attachment.bin