On 9/30/05, James Morris <jmorris(a)namei.org> wrote:
> type=AVC msg=audit(1128050967.120:12221195): avc: denied {
name_bind
> } for pid=10749 comm="sctp_test" src=1234
> scontext=root:system_r:unconfined_t tcontext=system_u:object_r:port_t
> tclass=socket
SELinux has no protocol-level support for SCTP yet, so the SCTP socket is
being classified by SELInux as a generic socket, but still being checked
by the protocol-level bind() permissions.
Other parts of the code make assumptions about IP & IPv6 sockets,
classifying them as either TCP, UDP or 'RAW' (which is a
catch-all for IP protocols notably including ICMP).
Ah, makes sense.
We could add a policy entry for unconfined_t to allow name_bind for
the
socket class, but we'd also hit problems where it defaults to a 'raw'
socket.
We can't simply classify SCTP as 'raw', as it has some different
semantics, such as multiple local and remote addresses, which we need to
investigate and develop proper controls for.
We proably need to rethink the way IP sockets default to 'raw', as new IP
protocols are sometimes developed (DCCP has just been implemented) and we
don't know that the 'raw' IP controls always appropriate.
In many cases the use of new protocols is so special use that it
wouldn't hurt to give apps raw until better support is added. For
example, a routing daemon speaking OSPF.
SCTP obviously will need full support, since it will eventually be
used as a general purpose transport in many applications and may
eventually supplant TCP and UDP in some places. It would be nice if
SElinux could step up to controlling the ability to control all
address bindings (i.e. application X can only form connections on the
secure network), but since they can be added and removed on an active
connection that might be interesting.
Is there currently the ability to control IPSec behavior from SElinux
(i.e. application X can only use TCP across an encrypted link), if so
that might provide some guidance in how to make some of the extra sctp
knobs look..