[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [V8 PATCH 11/11] virtio-9p: Chroot environment for

From: Venkateswararao Jujjuri (JV)
Subject: Re: [Qemu-devel] Re: [V8 PATCH 11/11] virtio-9p: Chroot environment for other functions
Date: Fri, 11 Mar 2011 07:23:23 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110303 Thunderbird/3.1.9

On 3/10/2011 10:30 PM, Stefan Hajnoczi wrote:
> On Fri, Mar 11, 2011 at 5:54 AM, Venkateswararao Jujjuri (JV)
> <address@hidden> wrote:
>> On 3/10/2011 4:29 AM, Stefan Hajnoczi wrote:
>>> On Wed, Mar 9, 2011 at 5:16 PM, M. Mohan Kumar <address@hidden> wrote:
>>>> Add chroot functionality for systemcalls that can operate on a file
>>>> using relative directory file descriptor.
>>> I suspect the relative directory approach is broken and escapes the
>>> chroot.  Here's why:
>>> The request is local_chmod(fs_ctx, "/..", credp).  dirname("/..") is
>>> "/" and basename("..") is "..".
>> We should never receive protocol operations with relative path.
>> Client should always resolve to full path and send the request.
>> If the client is malicious this scenario can be be possible.. but in that 
>> case
>> it is fine to fail the operation.
> What I haven't audited yet is whether symlinks can be abused in any of
> these *at(2) operations.

Reading symlink sends only contents to the client. So a symlink can contain
But when the fully populated path comes we avoid the potential symlink issue by
the entire dir in chrooted process.
> The *at(2) approach seems like a shortcut to avoid implementing
> individual chroot protocol requests/responses for stat(2) and friends.
>  But it carries the risk that if we don't use NOFOLLOW then we can be
> tricked into escaping the "chroot" because we're performing the
> operation outside the chroot.

I would agree with your observation. With *at(2) we need the following:

1. The path should never have ".." May be we can check it early enough and fail.
2. Get the pfd from the chroot_thread
3. use NO_FOLLOW.

If we do all three then we are fool prof.
> I'll take a look later today to make sure all operations safe traverse
> paths outside the chroot.

If we move all the operations to chroot, we are essentially serializing all
But the code looks lot cleaner though.

- JV

> Stefan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]