Quoting Michael Stone (michael@xxxxxxxxxx):
So far, two defaults have been proposed:
default-deny incompatible isolation (Pavel)
default-permit incompatible isolation (Michael)
So far, several signalling mechanisms have been proposed:
1) enabling a kernel config option implies default-permit
- My favorite; apparently insufficient for Pavel?
default under what conditions? any setuid? setuid-root?
2) default-deny; disablesuid grants disablenetwork
- "disablesuid" is my name for the idea of dropping the privilege of
exec'ing setuid binaries
- Suggested by Pavel and supported by several others.
- I think it has the same backwards-compatibility problem as
disablenetwork: disablesuid is an isolation primitive.
3) default-deny; dropping a capability from the bounding set grants "permit"
- Suggested by Serge; seems nicely fine-grained but rather indirect
Actually I think it's the opposite of what you said here: so long as the
capability is in pE, you can regain network. So it would require a privileged
process early on (like init or login) to remove the capability from the
bounding set (bc doing so requires CAP_SETPCAP), but once that was done,
the resulting process and it's children could not require the capability,
and, without the capability, could not regain network. Point being that
privileged userspace had to actively allow userspace to trap a setuid root
binary without networking.
I think during exec we can simply check for this capability in pE, and
if present then re-enable network if turned off. Then setuid-root binaries
will raise that bit (if it's in the bounding set) automatically. Now,
that means setuid-nonroot binaries will not reset network. Though you
could make that happen by doing setcap cap_net_allownet+pe /the/file.
Does that suffice?
4) default-deny; setting a sysctl implies permit
- Suggested by Serge; works fine for me
That still leaves the question of when we re-allow network. Any
setuid?
P.P.S. - On a completely unrelated note: imagine trying to use SELinux (or your
favorite MAC framework) to restrict the use of prctl(PR_SET_NETWORK,
PR_NETWORK_OFF). Am I right that sys_prctl() contains a
time-of-check-to-time-of-use (TOCTTOU) race (with security_task_prctl() as the
check and with prctl_set_network() as the use) as a result of the actual
argument being passed by address rather than by value?
I'm probably misunderstanding your question, but just in case I'm not: the
answer is that you wouldn't use the prctl interface anyway. You would strictly
use domain transitions. Instead of doing prctl(PR_SET_NETWORK, PR_NETWORK_OFF)
you would move yourself from the user_u:user_r:network_allowed domain to the
user_u:user_r:network_disallowed domain.