Sandbox Config Sample

This topic describes how to configure your sandboxed app, and find the root causes of sandbox related problems.

By default, all apps are sandboxed. If your app is written in C or C++, and only uses Legato APIs and standard libraries, then you may already be running your app in a sandbox without even knowing it. Sometimes you need more, and therefore, may be prevented from accessing something you need.

We'll use a trivial Python program example to demonstrate how to sandbox apps properly.

When shell command samples are provided, lines beginning with '$' are run on the development PC, and lines beginning with '#' are run on the target device (either through ssh or the serial console).

See Tutorials for details on on how to create Legato apps.

Create App

Create your hello.py app like this:

python
print("Hello world!")

Now create an .adef file called helloPython.adef that looks like this:

bundles:
{
file:
{
hello.py / /* bundle hello.py into the app, appearing in the root of the sandbox. */
}
}
requires:
{
file:
{
/usr/bin/python /usr/bin/ /* import python interpreter into /usr/bin in sandbox */
}
}
processes:
{
run:
{
( python /hello.py) /* run hello.py when the app starts */
}
}

Build and Install App

You're ready to build and install your sandboxed app:

$ mkapp helloPython.adef -t wp85 && update helloPython.wp85.update 192.168.2.2

Check Logs

To ensure everything fired correctly, you need to check your target's log:

# logread | grep helloPython

Oops, there's an error:

python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory

This is the dynamic linker telling us it can't find the library libpython2.7.so.1.0 that is needed by the python interpreter.

The library path /usr/lib/libpython2.7.so.1.0 /usr/lib/ needs to be added to the .adef in the requires/file section:

requires:
{
file:
{
/usr/bin/python /usr/bin/
/usr/lib/libpython2.7.so.1.0 /usr/lib/
}
}

If you're unsure of a library path, use find on the target device:

# find -name libpython2.7.so.1.0 /
/usr/lib/libpython2.7.so.1.0

Then you need to build and install it again:

$ mkapp helloPython.adef -t wp85 && update helloPython.wp85.update 192.168.2.2

Check the log, and it's still complaining about libutil.so.1, so we add /lib/libutil.so.1 /lib/ to the requires/files section:

requires:
{
file:
{
/usr/bin/python /usr/bin/
/usr/lib/libpython2.7.so.1.0 /usr/lib/
/lib/libutil.so.1 /lib/
}
}

Using strace

If the logs don't indicate what the problem is, you can use strace to trace all the system calls that the program performs, and look for failed calls to open().

Do this by changing adding strace -f in front of your program name in the processes/run section of the .adef:

processes:
{
run:
{
( strace -f python /hello.py) /* run hello.py when the app starts */
}
}

Requiring Whole Directories

Continuing your investigation, you find your app needs stuff from /usr/lib/python2.7 and /usr/include/python2.7.

There's a lot of stuff in there. You know it's safe to allow your app access to all of it. To save you the hassle of going through the discovery process for each individual file in the directories your program might need, you can just add the whole directories to your sandbox using a requires/dir section in your .adef:

requires:
{
dir:
{
/usr/lib/python2.7 /usr/lib/
/usr/include/python2.7 /usr/include/
}
}

Environment Variables

The log will now display something like:

getpwuid(): uid not found: 1017

.

You need to set the environment variables. For our py example, you add this to the .adef file processes section:

envVars:
{
HOME="/"
}

Sandbox Working Correctly

Viewing the logs one more time, you see:

INFO | python[8816] | Hello world!

Congratulations! You have shown that you care about security and are proving yourself to be a thorn in the side of hackers and an asset to your developer community, the greater Internet community, and all those who might be affected by vulnerabilities in networked devices. We sincerely thank you!