Forwarding to a wider audience. IMO, this topic spans both security and
networking.
-Krishna
--- Begin Message ---
Hello,
my name is Johannes Nicolai and I am responsible for expanding the basic
privilege set in order to have the possibility to restrict network access (even
for non privileged ports). After I became familiar with privileges(5),
compiling OpenSolaris from source and using BFU, I now have my first questions
to the security community regarding my task. Perhaps some of you may provide me
with hints or point out interesting resources where I can get further answers.
First of all, the problem description on the SoC page was:
"Expansion of basic privileges: OpenSolaris uses privileges both for process
empowerment and also has a currently small set of basic privileges that can be
removed to restrict processes. The basic set should be enhanced so that inbound
and outbound network access can be restricted even for non privileged ports."
Just to clarify inbound and outbound: I assume that outbound traffic means
traffic originated by the process (e. g. via connect or sendto) and inbound
traffic something that resulted from accept or recfrom. This defines inbound
and outbound according to the initiation and not to the data flow (to my mind,
restricting the data flow for a duplex connection may not make much sense).
My question is whether there should be any possibility to restrict inbound
connections but not outbound connections or vice versa.
To my mind, this may be useful to some kind but would complicate the
understanding of the new privileges, so I would not do so.
The second questions relates to the question whether the new capabilities
should be more detailed (like PRIV_NET_CONNECT / PRIV_NET_BIND /
PRIV_NET_ACCEPT...) or more general (like PRIV_NET_ALLOWNETWORKTRAFFIC). To my
mind, the second alternative looks much easier for the
programmer/administrator, because it is only one privilege and not a whole
bunch (see monitored system calls at the end of the mail).
The third question is whether open network connections should continue to
function.
Consider already open network connections (perhaps hidden as stdin/stdout if
spawned by inetd), working with the X-Server, delegation (the process uses
another process via IPC to communicate with the rest of the world (e. g. recv
to receive already open file descriptors)).
Otherwise, perhaps every read and write operation has to be monitored (I am not
sure whether the read and write operations will be redirected to call to
send/recv, are they?).
Stateless connections should not be considered to be already established,
should they?
On the other hand, things get really complicated if one have to decide whether
to allow a sendto/sendmsg or recvfrom, recvmsg call: It will depend on the
socket type (stateless, stateful), whether this is regarded as an already
established connection.
I have no decision for this point at the moment, but it is perhaps the most
important design question for my task at all.
The fourth questions dealss with treatment of different protocol types: Should
Unix domain socket communication also be denied if the privilege(s) is/are not
present any more? One could argue that then one have to deny semaphores,
message queues and shared memory as well because all mechanism are only for
local IPC. To my mind, one should deny Unix domain socket communication as
well. It is only a protocol out of many. On the other hand: Are local
connections considered to be inbound/outbound?
The fifth big question deals with possible system calls (actually, I do not
know whether this are really different system calls in OpenSolaris or only
varaints of one big system call, because I have not digged deep enough into the
code yet, may you point out resources I can read to get fit with the networking
code in Solaris?), I have to change in order to restrict network access. Please
tell me, if I forgot something. The interfaces of these calls are quite stable,
but not in any case, a sensible return code for "permission denied" is already
present. Should I introduce new return codes in this case?
---
socket: Should new socket creation should be forbidden? To my mind, why not? I
would return EACCES in case of the missing privilege (already defined in
interface)
socketpair: It is only IPC, but I would also deny this (return code: EACCES)
setsockopt: Should this be denied? There would be no sensible return code in
the interface for this purpose.
bind: Should be denied, return code: EACCES
connect: Should be denied, return code: EACCES
read: Is this call is redirected to recv in the kernel (need further
information about the network code in the kernel)? See recv
write: Is this call is redirected to send in the kernel (need further
information about the network code in the kernel)? See send
accept: Should be denied, but no sensible return code in the interface
send: Depends, whether already open connections should be denied, no sensible
return code in the interface
sendto: Should be denied at all (if one decides to restrict already open
connections as well) or at least for stateless connections, no sensible error
code in the interface
sendmsg: Should be denied at all (if one decides to restrict already open
connections as well) or at least for stateless connections, no sensible error
code in the interface
recv: Depends, whether already open connections should be denied, no sensible
return code in the interface
recvfrom: Should be denied at all (if one decides to restrict already open
connections as well) or at least for stateless connections, no sensible error
code in the interface
recvmsg: Should be denied at all (if one decides to restrict already open
connections as well) or at least for stateless connections, no sensible error
code in the interface
shutdown: No really sure yet, whether to deny this call, but tend to yes, no
sensible return code in the interface
close: Is close redirected to shutdown? See shutdown
flush on already existing socket descriptors: Should flushing data in socket
buffer be allowed generally? No real idea, yet, but tend to yes.
fcntl on already existing socket descriptors: No real idea, yet, but tend to
allow everything, even to install signals that new data is available. If one
decide to deny it instead, EPERM is already defined in the interface.
select/poll on already existing socket descriptors: Should be generally
allowed, but data cannot be read. No sensible return code to indicate a lack of
privileges is present in the interface.
door_call/t_open: Just stumbled over this things when I trussed a simple
application that uses gethostbyname. It seems as if gethostbyname uses the door
to nscd and also uses t_open(/dev/udp). These concepts are new too me, I do not
really know, whether this mechanism should be denied in order to restrict
delegation attacks.
---
As you see, there are lots of possible calls to restrict, so introducing a
single privilege for every call might not be a good idea.
My last question deals with possible privilege escalation and thoughts about
declaring the new privilege(s) as unsafe.
Should one need the new privilege(s) in order to get PRIV_NET_BINDMLP,
PRIV_NET_ICMPACCES, PRIV_NET_MAC_AWARE, PRIV_NET_PRIVADDR,
PRIV_NET_RAWACCESS,PRIV_SYS_DEVICES and further privileges that can be used to
bypass the socket interface?
Should the new privilege(s) be considered as unsafe (perhaps they are needed
for host name resolution or using nfs mounts).
Questions over questions, I hope you can provide me with some ideas.
Thanks in advance
Johannes
_______________________________________________
security-discuss mailing list
[EMAIL PROTECTED]
--- End Message ---
_______________________________________________
networking-discuss mailing list
[email protected]
