I think your surmise is correct, they are inherited from the parent namespace. This seems similar to how processes clone themselves using the
fork() system call, then any desired changes have to be applied by the clone, using the normal system calls. (Including replacing the current program with a completely different one, using
exec() being how e.g. the shell runs other programs, although this magic is not usually visible to the user).
None of the options to the underlying
unshare system call change this. So I'd say the answer to your question is no.
Oh... that wasn't even an analogy! Look at the option flags:
CLONE_NEWNET (since Linux 2.6.24)
This flag has the same effect as the
flag. Unshare the network namespace, so that the calling
process is moved into a new network namespace which is not
shared with any previously existing process. Use of
CLONE_NEWNET requires the CAP_SYS_ADMIN capability.
clone() basically means
Since version 2.3.3, rather than invoking the kernel's fork() system
call, the glibc fork() wrapper that is provided as part of the NPTL
threading implementation invokes clone(2) with flags that provide the
same effect as the traditional system call. (A call to fork() is
equivalent to a call to clone(2) specifying flags as just SIGCHLD.)