Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

linux_env - FileSystem::resolve_path and FileSystem::readlink seems incompatible #1116

Open
Sh3idan opened this issue Dec 24, 2019 · 3 comments

Comments

@Sh3idan
Copy link
Contributor

Sh3idan commented Dec 24, 2019

My architecture:

file_sb/
├── home
│   └── user
│       └── bin.elf
└── proc
    ├── 1000
    │   └── exe -> /home/bla/[TRUNCATED]/file_sb/home/user/bin.elf
    └── self -> 1000

FileSystem::resolve_path reads link and breaks FileSystem::readlink function because of wrong return value. See below:

[syscalls][sys_x86_64_readlink][DEBUG]: sys_readlink('/proc/self/exe', 13f028, fff)
[environment][readlink][DEBUG]: readlink('/proc/self/exe')
[environment][resolve_path][DEBUG]: resolve_path(path='/proc/self/exe', follow_link=False)
[environment][resolve_path][DEBUG]: -> '/user/bla/[TRUNCATED]/file_sb/home/user/bin.elf'
[environment][readlink][DEBUG]: '/user/bla/[TRUNCATED]/file_sb/home/user/bin.elf' is not a link
[syscalls][syscall_x86_64_exception_handler][DEBUG]: -> ffffffffffffffff
@commial
Copy link
Contributor

commial commented Jan 3, 2020

Hi,

It might not be the best solution, but the way I saw it, the filesystem should be relative to the sandbox root. Ie, it should work the same way than a chroot, so the link should point to /home/user/bin.elf on order to work properly.

The current implementation might be buggy, but what do you think about this way of doing?

@Sh3idan
Copy link
Contributor Author

Sh3idan commented Jan 12, 2020

Hi,

Right now, with symbolic which point to /home/user/bin.elf, FileSystem::resolve_path + FileSystem::readlink return a non-sandboxed link. See below.

file_sb/
├── home
│   └── user
│       └── bin.elf
└── proc
    ├── 1000
    │   └── exe -> /home/user/bin.elf
    └── self -> 1000
[syscalls][sys_x86_64_readlink][DEBUG]: sys_readlink('/proc/self/exe', 13f028, fff)
[environment][resolve_path][DEBUG]: resolve_path(path='/proc/self/exe', follow_link=False)
[environment][resolve_path][DEBUG]: -> '/home/user/bin.elf'
[syscalls][syscall_x86_64_exception_handler][DEBUG]: -> ffffffffffffffff

the filesystem should be relative to the sandbox root. Ie, it should work the same way than a chroot, so the link should point to /home/user/bin.elf on order to work properly.

It could be nice. I have one question about it : What happens if the link is valid? I think it's still good, are you agree?

What do you think about getting target of symbolic link only if follow_link is True and following these steps to solve link?

  • readlink(path)
    • sys_x86_64_readlink(path, ...)
      • FileSystem::readlink(path)
        • resolving link name (path)
          • resolve_path(path, follow_link=False)
        • getting target
          • os.readlink(sb_path)
        • resolving target
          • resolve_path(target, follow_link=False)
        • ret sb_target
      • ret sb_target
    • ret sb_target

@commial
Copy link
Contributor

commial commented Jan 15, 2020

Hi,

I'm not sure to understand the step description, but we're maybe saying the same thing.

IMHO, we want two things:

  • A simple to understand behavior, such as the chroot one
  • Avoid Sandbox escape. By default, it should not be possible to fail yourself by copying any kind of file inside the file_sb directory, such as link to an existing, outside of file_sb, file.

So, if the follow_link is not set, it should never resolve the link. Does it seems OK to you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants