Currently, sandbox is only activated when $PWD is in a directory restricted by a profile. However, if user accidentally runs a binary present in a sanboxed directory, while the working directory is a non-sandboxed directory, the binary will be executed without restrictions.
Basically, I'm worried about the following scenario: user uses profiles to create separate sandboxes for different applications. User forgets to enter sandbox directory before executing the application. Application runs with full user's privileges.
I can totally see myself making that mistake as I often run applications by typing a relative path.
Example (redundant)
~ % mkdir test
~ % cd test
~/test % cp /bin/ls .
'/bin/ls' -> './ls'
~/test % ./ls /
bin boot dev efi etc home lib lib64 lost+found mnt opt proc root run sbin srv sys tmp usr var
~/test % island create test
Created profile "test" in /home/user/.config/island/profiles/test
It applies to:
- /home/user/test
~/test % ./ls /
ls: cannot open directory '/': Permission denied
~/test % cd ..
~ % ./test/ls /
bin boot dev efi etc home lib lib64 lost+found mnt opt proc root run sbin srv sys tmp usr var
This may be hard/out of scope to solve in the general case, but maybe something could be done to make this less likely.
One solution I came up with, is to have an auto-generated default profile that prevents executing binaries from all sandboxed directories. Island could also check if executed binary is placed in a sandboxed directory, apply matching profiles and/or warn the user. [1]
That doesn't work for scripted languages, unless reading files from a sandboxed directory would also be forbidden.
Restricting reading would make copying files between the sandbox and the rest of the system inconvenient. Maybe profiles could also have a special directory for the purpose of sharing files? Or there could be a list of commands that are exempt from this default profile?
[1] Applying the profile instead of warning the user might be confusing. If a non-shell script tries executing the same application, it will fail.
Currently, sandbox is only activated when $PWD is in a directory restricted by a profile. However, if user accidentally runs a binary present in a sanboxed directory, while the working directory is a non-sandboxed directory, the binary will be executed without restrictions.
Basically, I'm worried about the following scenario: user uses profiles to create separate sandboxes for different applications. User forgets to enter sandbox directory before executing the application. Application runs with full user's privileges.
I can totally see myself making that mistake as I often run applications by typing a relative path.
Example (redundant)
This may be hard/out of scope to solve in the general case, but maybe something could be done to make this less likely.
One solution I came up with, is to have an auto-generated default profile that prevents executing binaries from all sandboxed directories. Island could also check if executed binary is placed in a sandboxed directory, apply matching profiles and/or warn the user. [1]
That doesn't work for scripted languages, unless reading files from a sandboxed directory would also be forbidden.
Restricting reading would make copying files between the sandbox and the rest of the system inconvenient. Maybe profiles could also have a special directory for the purpose of sharing files? Or there could be a list of commands that are exempt from this default profile?
[1] Applying the profile instead of warning the user might be confusing. If a non-shell script tries executing the same application, it will fail.