Hi all,
Don't know if these are the results of a standard security mechanism
or configurable option in FreeBSD 4.6. Here are the findings:

* A server process can bind, listen, accept and even read from a TCP
socket, created by socket(AF_INET, SOCK_STREAM, 0).

* But it is not permitted to write to the socket as the system call
returns errno = EACCES/13, quoting "Permission denied".

* The error occurs only when the client runs on a remote host. It
works fine for local TCP clients.

* The server process is run as non-root. fstat() reveals that the
socket has the owner's write permission bit (S_IWUSR) enabled.

* mSQL 2.0.4 daemon and a home-grown TCP/IP echo program are used as
examples of the said server process.

* No shutdown() call is ever invoked by the mSQL daemon (according to
ktrace) or my echo program to make the socket read-only.

Can someone tell me if such observations are expected from a hardened
FreeBSD 4.6 system, or they are rather symptoms of a ill-behaved
environment? If the latter is the case, any workaround or fix
available?

Thanx

Sunny Suen wrote:
> Hi all,
> Don't know if these are the results of a standard security mechanism
> or configurable option in FreeBSD 4.6. Here are the findings:
> 
> * A server process can bind, listen, accept and even read from a TCP
> socket, created by socket(AF_INET, SOCK_STREAM, 0).
> 
> * But it is not permitted to write to the socket as the system call
> returns errno = EACCES/13, quoting "Permission denied".
> 
> * The error occurs only when the client runs on a remote host. It
> works fine for local TCP clients.
> 
> * The server process is run as non-root. fstat() reveals that the
> socket has the owner's write permission bit (S_IWUSR) enabled.
> 
> * mSQL 2.0.4 daemon and a home-grown TCP/IP echo program are used as
> examples of the said server process.
> 
> * No shutdown() call is ever invoked by the mSQL daemon (according to
> ktrace) or my echo program to make the socket read-only.
> 
> Can someone tell me if such observations are expected from a hardened
> FreeBSD 4.6 system, or they are rather symptoms of a ill-behaved
> environment? If the latter is the case, any workaround or fix
> available?
> 
> Thanx

Why would you ever write to a listen socket?  Who would be the receiver
of the message?  When you do an accept(), you get a communications
endpoint that is connected to another program.  A bound listen socket
is connected to no one.

--

Fletcher Glenn

Fletcher Glenn <fletcher@removethisfoglight.com> wrote in message news:<4085486D.3030304@removethisfoglight.com>...
> Sunny Suen wrote:
> > Hi all,
> > Don't know if these are the results of a standard security mechanism
> > or configurable option in FreeBSD 4.6. Here are the findings:
> > 
> > * A server process can bind, listen, accept and even read from a TCP
> > socket, created by socket(AF_INET, SOCK_STREAM, 0).
> > 
> > * But it is not permitted to write to the socket as the system call
> > returns errno = EACCES/13, quoting "Permission denied".
> > 
> > * The error occurs only when the client runs on a remote host. It
> > works fine for local TCP clients.
> > 
> > * The server process is run as non-root. fstat() reveals that the
> > socket has the owner's write permission bit (S_IWUSR) enabled.
> > 
> > * mSQL 2.0.4 daemon and a home-grown TCP/IP echo program are used as
> > examples of the said server process.
> > 
> > * No shutdown() call is ever invoked by the mSQL daemon (according to
> > ktrace) or my echo program to make the socket read-only.
> > 
> > Can someone tell me if such observations are expected from a hardened
> > FreeBSD 4.6 system, or they are rather symptoms of a ill-behaved
> > environment? If the latter is the case, any workaround or fix
> > available?
> > 
> > Thanx
> 
> Why would you ever write to a listen socket?  Who would be the receiver
> of the message?  When you do an accept(), you get a communications
> endpoint that is connected to another program.  A bound listen socket
> is connected to no one.

It is the socket returned by accept() that the server is not permitted
to write to. Should have elaborated a bit more. What I mean is that
the server can create, bind and listen on a long-standing socket, from
which a new one is accepted and readable but not write-able whenever a
connection request is issued from a client. Hence, it's a standard
TCP/IP server process.

Another point I've forgotten to mention is that an Apache web server
is being smoothly run as a non root user on the system. So naturally,
the web server socket is write-able for this web server user account.

Looks like a kernel-level access control framework is in force
somewhere and somehow to harden the box. As a FreeBSD newbie, just
found that version 5.0/higher is capable of similar features, known
collectively as Mandatory Access Control (MAC). But the system in
question is FreeBSD 4.6, where MAC is absent.

Might as well settle on the guess that the kernel, or system calls, to
be exact, could have been patched by some customised hacks to deny the
write permission of any TCP socket to all non root users except some
special accounts, regardless of the sockets' ownership.

Appreciate any suggestions or comments.