(originally published on 03.04.2019, reviewed/rewritten on 27.03.2025, tested on Solaris 11.4 SRU 79)
Access to the network is a privilege in Solaris for quite some time now. It’s nothing you have nescessarily the right to just by being a user on a system. It’s just the way that you have this privilege by default to ensure a default configuration doesn’t break things.
It’s really easy in Solaris to run in an environment that doesn’t have this privilege. For example because you know that your application doesn’t need network access and thus want to be sure that it doesn’t have it. For example when testing software and you want to be sure, that it doesn’t accesses another system in case you forgot to disable something.
In Solaris 11.4 you can use the sandbox command for this. Without further options, you run the command in a sandbox with the privilege to access the network.
root@testbed:~# sandbox "curl http://www.c0t0d0s0.org"
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
(...)However if you use the sandbox with the -n option, the command you are specifying to run inside the sandbox don’t have the privilege to use the network
root@testbed:~# sandbox -n "curl http://www.c0t0d0s0.org"
curl: (7) Failed to connect to www.c0t0d0s0.org port 80 after 5 ms: Could not connect to serverThe difference between both command is the set of privileges that is given to the processes inside the sandboxes.
root@testbed:~# sandbox -n "bash"
root@testbed:~# ppriv $$
1277: bash
flags = PRIV_AWARE|PRIV_XPOLICY
Extended policies:
{proc_exec}:/root/*
{proc_exec}:/usr/*
E: basic,!net_access,!proc_exec,!proc_info,!proc_session
I: basic,!net_access,!proc_exec,!proc_info,!proc_session
P: basic,!net_access,!proc_exec,!proc_info,!proc_session
L: basicThe privilege to access the network has been explicitly removed by the !net_access in the privilege set. A sandbox without the-n doesn’t have this limitation. So you can use the network.
root@testbed:~# sandbox "bash"
root@testbed:~# ppriv $$
1284: bash
flags = PRIV_AWARE|PRIV_XPOLICY
Extended policies:
{proc_exec}:/root/*
{proc_exec}:/usr/*
E: basic,!proc_exec,!proc_info,!proc_session
I: basic,!proc_exec,!proc_info,!proc_session
P: basic,!proc_exec,!proc_info,!proc_session
L: basicBy the way: I used the root user to show that this limitation is even in place for processes running with root or root-eqivalent privileges.
