Maybe: run a command, see what it does to your files without actually doing it

by colund • 10 years ago

515 94 10 years ago

gravypod2• 10 years ago

THIS IS AMAZING! I would have never imagined seeing something this useful being made in my life.

jldugger• 10 years ago

It's actually quite simple. LD_PRELOAD can achieve a similar effect, if the software is using the typical syscall library.

gravypod2• 10 years ago

I know exactly how it was done, I am just amazed that it was done. It's a great idea that I have never come up with, nor would I be able to.

throwaway2048• 10 years ago

I wouldn't rely on it being safe, it makes a lot of assumptions that programs that do destructive things might violate.

Mithaldu• 10 years ago

I feel like this would only be useful for badly written software.

Anything reliable would check that its operations went through as expected and bail really early.

millstone• 10 years ago

Reliable software should definitely check returns codes, but maybe returns success. Inspecting the filesystem to verify the result is overdoing it, and race-y besides.

emmelaich2• 10 years ago

It's one of those things that change in tone when expressed in the second or third person.

When I do tests, they are the unmistakable sign of good careful programming.

When you do tests it's an expression of lack of confidence.

Whey they do tests it's a sure sign that really don't know what the hell they're doing.

:-) in case it's needed

striking• 10 years ago

Sometimes you don't have a choice.

tgamblin• 10 years ago

It's intercepting system calls with ptrace, so it could easily fool the process into thinking its calls did exactly what was expected. A cursory glance through the code indicates that it mostly does. However, it looks like it doesn't record changes to files so that they could be read back in by the application. So this will work for applications that read once and write once, but if the same file is written and read, it'll probably break.

pablooa• 10 years ago

This is what I immediately thought. This command should not be considered fail-proof. Even if you're fooling the caller returning successes when actually doing nothing, the trace displayed by this command can't be considered exactly what the program, running without being traced, would have done.

wingerlang• 10 years ago

Sometimes I write a script that I am 99% sure that is correct. Let's say I write a regex that should delete files with a specific pattern. With maybe, I could run it and see the files it /actually/ intend to delete with a dry run.

I might not want to actually delete them without confirming it.

HerraBRE• 10 years ago

My favourite pattern for this use-case is to write script A that generates script B; instead of A invoking 'rm' directly, it runs 'echo rm', or even 'echo #rm'.

Then I open up script B in an editor and review the planned changes. Once I like what I see (potentially after a few edits) I run 'bash B'.

tluyben2• 10 years ago

Very nice example of the python ptrace library and OS internals.

burrows2• 10 years ago

This would be more useful if it used a virtual file system.

What happens if the program writes a bunch of stuff to disk then later on tries to read it?

gruez• 10 years ago

based on the README, the syscalls are intercepted and are not emulated, so the program will read back the original file.

peteretep• 10 years ago

An additional value of that approach would be you could then decide you wanted to keep the results

qb452• 10 years ago

I wonder if it would be possible to use btrfs snapshotting for that.

whenov• 10 years ago

  #!/bin/bash

  touch x

  if [ -f "x" ]; then
      rm -rf /
  else
      echo "I'm just an innocent little script."
  fi

singlow• 10 years ago

rm -rf --no-preserve-root

mapcars• 10 years ago

In Plan9 one could create clean separate filesystem and run unsafe program there, or, make a filesystem server which logs each of ~20 api calls of 9p protocol, since they are all you have to manipulate files.

qb452• 10 years ago

Something like unionfs/overlayfs, which are the magic allowing Linux Live CDs to "modify" files and directories stored on read-only medium.

https://www.kernel.org/doc/Documentation/filesystems/overlay...

widdma• 10 years ago

Mbox does exactly this: https://pdos.csail.mit.edu/archive/mbox/

mappu• 10 years ago

It doesn't work this way, but my first expectation was that this would take an LVM2/ZFS snapshot and diff the file trees afterward. Then it'd be easily ported to Windows (VSS) and wouldn't have the subprocess issues on *BSD, but, the diff would be slower, unordered, and contain changes made by unrelated processes.

dfc• 10 years ago

Comparing two snapshots would convert multiple modifications into one big change.

the8472• 10 years ago

combining the ptrace approach for logging with mount namespaces, snapshotting or overlayfs would probably be more consistent approach if the program actually tries to use the files.

just stubbing out the system calls sounds like it'll quickly break down once the programs try to do something more complicated with the files.

markbnj• 10 years ago

Looks like a very interesting and potentially powerful diagnostic tool. Nice work!

agumonkey• 10 years ago

Anybody remember cleansweeper ?

OJFord2• 10 years ago

This is awesome, I hope some Mac user with the know-how sees this and is motivated to get python-ptrace on Darwin...

lunixbochs2• 10 years ago

You don't actually get PTRACE_SYSCALL on OS X, so you need to play with dtrace or dynamic recompilation to get this kind of tool.

OJFord2• 10 years ago

My understanding is that support for the ktrace back-end is (/was/will be) upcoming for python-ptrace. Unfortunately I don't have the skills for that, but what I meant is that I hope someone will; then tools like `maybe` can presumably use python-ptrace in just the same way as other Unices?

dantillberg• 10 years ago

I'm imagining someone trying something along these lines:

maybe find ~/ | grep . | parallel rm {}

...and be fairly surprised to find everything deleted. It wasn't find's fault!

ecma2• 10 years ago

Why would anyone ever invoke something like this and expect maybe to somehow steal those pipe characters? It's almost meaningless and displays just enough know how that the author should know how a shell works.

geofft• 10 years ago

Have you never run something like "sudo echo 0 > /proc/sys/..." and only realized your mistake after running it? Ever?

lowglow2• 10 years ago

This is dope. I also wish there was better formatting/coloring/more info for dtruss/ptrace in general.

lowglow2• 10 years ago

s/ptrace/strace/

13of40• 10 years ago

Kind of like -whatif in PowerShell, if anyone bothered to implement it right.

majke• 10 years ago

Nice idea. Shameless plug: this reminds me a ptrace hack I did a couple years back:

fluxcapacitor

https://github.com/majek/fluxcapacitor#fluxcapacitor

https://idea.popcount.org/2013-07-19-how-to-sleep-a-million-...

rcthompson• 10 years ago

I'd wonder if this could be implemented more robustly on ZFS using some snapshot magic.

GigabyteCoin• 10 years ago

I would have used something like this when I was first learning rsync...

Even though I had read all of the man pages and knew the commands inside and out, it still seemed incredibly risky and scary to me to run rsync with the --delete function when I was backing up my main USB drive for the very first time.

Basically my biggest fear was that I had source and destination mixed up, which I didn't, but it would have been nice to run a test trial of that command before doing so.

P4bTXfOZAZicOOw• 10 years ago

From man rsync:

    -n, --dry-run               perform a trial run with no changes made

This probably also would have helped

bentaber• 10 years ago

Wouldn't the rsync --dry-run flag be helpful in that scenario?

SixSigma2• 10 years ago

did cp not work on your system ?

cyphar3• 10 years ago

rsync has integrity checking and is better in quite a few ways.

sry_not4sale• 10 years ago

I use Docker to achieve a similar thing...

1) Boot up a new Ubuntu docker container 2) Run command / script 3) Use `docker diff` to see what changes to the filesystem were made

Obviously it's only useful for some commands, but at least it's safe :-)

frik2• 10 years ago

Ideally, you want ad hoc sandbox (like Sandboxie on Win32)

Ideally, Docker could offer ad hoc commands to launch an process in a sandbox. And then you launch a file explorer process in the same sandbox (like Sandboxie) to inspect or run a diff-tool that outputs statistics like the tool in the headline.

dkarapetyan2• 10 years ago

libguestfs can be used to do the diffing. Create the initial disk, do stuff in VM, use libguestfs to do diff. I almost built a hacky omnibus packaging tool this way. I say almost because it turns out to be just as simple to just compile stuff from source and install in /opt and then package those files.

ptman• 10 years ago

This is like Sandboxed Execution Environment https://github.com/F-Secure/see which was originally created for malware testing. And yes, we used guestfs.

lugus35• 10 years ago

On Windows you have sandboxie (http://www.sandboxie.com), a complete sandbox for your programs.

viraptor2• 10 years ago

I didn't know something like that exists. I knew of win10 app sandboxes, but this is even more generic. I'll definitely use it whenever possible.

I got so used to this being relatively easy on linux (grsec, firejail, seccomp, etc.), but never heard of easy ways to apply it on win.

frik2• 10 years ago

relatively easy on linux

Please give me an example how to launch a program in a sandbox incl virtual FS on Linux - with Sandboxie it takes a single mouse click

Cyph0n• 10 years ago

Ah, I used to use Sandboxie way to run programs that were known malware. Good days :)

im2w1l• 10 years ago

Suggestion: Add a way to distinguish between parameters sent to maybe and parameters sent to the program. You don't accept any parameters at the moment, but you may want to in the future, and when you start wanting to do that, you may not want to break any existing usages by changing behavior. For that reason I think it would be good to introduce disambiguation now.

rvalue• 10 years ago

I like the work but Is it possible that "maybe" you don't catch something and it actually happens?

lucb1e2• 10 years ago

Yes, that is possible. As it says in the readme file:

maybe should :warning: NEVER :warning: be used to run untrusted code on a system you care about! A process running under maybe can still do serious damage to your system because only a handful of syscalls are blocked. Currently, maybe is best thought of as an (alpha-quality) "what exactly will this command I typed myself do?" tool.

caioariede• 10 years ago

Mbox does something similar, but seems to be more robust/complete: https://pdos.csail.mit.edu/archive/mbox/

txutxu• 10 years ago

Limited scope... this is local.

I use to implement a --trial in my shell scripts, which covers reporting of ALL operations (local and remote).

Anyway, this is a nice discover and nice hack.

paulasmuth2• 10 years ago

While this looks like a nice idea on paper, I would not recommend to use the current implementation of 'maybe' on a system that hosts valuable data.

The tool seems to work by intercepting individual "blacklisted" system calls and then - instead of executing them - returning a nonsense value.

The issue is that this breaks every single POSIX spec and will therefore break any program that does more than a few trivial IO operations and relies on those operations to behave as specified.

So it might work for a simple demo case where a small script only does a single file modification and never checks the results, but for any serious program (think a database, a complex on-disk format or really anything that does network IO) this will lead to corruption and undefined behaviour as system calls will return erroneous success values or invalid file descriptors.

I think to actually make this work one would have to emulate the system calls and make sure everything stays POSIX compliant. Doing this correctly for calls like mmap might get tricky though (and won't be possible from within a python runtime). And even then it isn't obvious how something like network IO would be handled.

bcook2• 10 years ago

My simple Perl todo script (either writing or reading a text file) causes the "maybe" program to fail while partially reading/outputting the todo archive file.

paulasmuth2• 10 years ago

Yes, the current 'maybe' implementation should practically break almost any properly written IO code.

At this point, it will only work for the most trivial of demo cases. Still IMO it's a cool demonstration of the linux ptrace facility. And if the author implements the missing sandboxing/emulation layer in a future version and switches to whitelisting instead of blacklisting syscalls I think it could actually run a limited number of programs (forbidding stuff like mmap and network IO).

DavideNL2• 10 years ago

Obviously, that's why the Github description says:

That being said, maybe should :warning: NEVER :warning: be used to run untrusted code on a system you care about! A process running under maybe can still do serious damage to your system because only a handful of syscalls are blocked. Currently, maybe is best thought of as an (alpha-quality) "what exactly will this command I typed myself do?" tool.

jacobparker• 10 years ago

You've missed Paul's point I think. Even running trusted code is unlikely to work as desired (and could still have negative consequences due to what isn't included in the "sandbox") for anything other than trivial programs.

zx2c4• 10 years ago

Also check out mbox:

https://pdos.csail.mit.edu/archive/mbox/

It's a bit more complete than this.

dontdieych• 10 years ago

I've used [mbox][0], [firejail][1] for this case.

    mbox COMMAND

run COMMAND and shows you what files changed. Then you can select drop or commit those files.

    $ mbox mktemp
    /tmp/tmp.cfJElOQmNK
    Sandbox Root:
    > /tmp/sandbox-30749
    > F: /tmp/sandbox-30749/tmp/tmp.cfJElOQmNK
    F:/tmp/tmp.cfJElOQmNK
    [C]ommit all, [c]ommit, [i]gnore, [d]iff, [l]ist tree, [q]uit ?> q
    $


    firejail --private=/path/to/home-for-command COMMAND

does similar things. But it only sandbox $HOME. Also does not show what is changed by defult.

[0] https://github.com/tsgates/mbox

[1] https://firejail.wordpress.com/

amelius4• 10 years ago

Sadly, it is not possible to combine this tool with programs that use ptrace themselves, because of limitations in the implementation of ptrace.

In Linux, a program that is being ptraced is not allowed to ptrace another program.

deutronium• 10 years ago

That's interesting, I never knew that. I wonder why that use case isn't possible.

amelius4• 10 years ago

You can try it yourself by running "strace" on itself, e.g.:

  strace -f strace -f ls

I guess this isn't possible because the kernel developers only envisioned ptrace to be useful for debugging (they supposedly didn't think about sandboxing applications), and implementing a "recursive" version of ptrace is probably more difficult.

andreygrehov• 10 years ago

Would it be more safe to copy the entire target to a /tmp and do all the required operations from there?

lucb1e2• 10 years ago

If you chroot there, maybe. Not sure I understand your question though.

malka• 10 years ago

Could not it be possible with docker or like to run a command in a sandboxed environment, and then provide a diff ?

amelius4• 10 years ago

Another option is to use a filesystem with rollback capabilities.

effie• 10 years ago

Do you know any examples?

amelius4• 10 years ago

For example btrfs or zfs.

_Marak_• 10 years ago

This seems neat, but from a security standpoint I'd much rather see a command which spawned a new VM with a copy of my current file-system.

I would then want to capture all disk and network i/o that the "maybed" command generated in the VM.

Even that wouldn't be that secure, because the command would still be able to send sensitive data out. You could intercept the network i/o, but that would cause most installers to fail.

bobp127001• 10 years ago

A really cool idea. Is this more or less how rootkits work and hide themselves? A system call is made to list the contents of a directory, and the rootkit excludes itself from that listing?

aug-riedinger• 10 years ago

Instead of a control approach: having to confirm every little action in there, It would be nicer to have a undo-able behavior: I actually run the script on the first time, but I can easily undo it if it did not work as expected. The current state of the art is of no use for me.

Maybe: run a command, see what it does to your files without actually doing it

Related Stories