Bug 238319

As already mentioned in the summary this is not actually a bug report per se,
but a proposal to extend the OS with completely new functionality.

- 1st I would like to propose making the session login name field sort of
write-once-read-many (WORM) field when kern.securelevel is above 0.
That would allow setting the login name once for each new session when
it has not been set before. Making it immutable when it has been set
would give he field content quite a lot credibility later for security
related actions or logging.

- 2nd I would like to propose adding a few completely new data items
in the session struct. These would be the address family and source address
for any IPC connections independent of whether it is LOCAL/UNIX or over
a proper network connection. Maybe even the protocol and source port should
be included when applicable. Obviously making such fields WORM similarly
to what I proposed for session login name above would be logical.
The benefit of having such address data available in a reliable manner
later in the session would make it very hard for any user or process to
hide the true origin of the session.
That would further allow for better security related decisions based
on where the session originates.
Maybe some services, their features, or actions should be limited purely
to local users, to users in a certain city, to users in a certain larger
geographic region, to users within a certain country, to users on a certain
continent, or maybe users from within any EU country but not others, etc.

In many cases the application server only inherits a local socket or a pty
from the actual network daemon. Without seeing the actual network socket
the child process has no access to the origin information available through
calls to getpeername() and getsockopt(). This then leads to weird attempts
to pass the true session origin to child processes in environment variables
(e.g SSH_CLIENT) or to other unreliable ad hoc methods to passing on the
information while leaving it in worst case modifiable to an intruder.

In some cases there might have to be distinct versions of the same service
provided to users from distinct origins. In some cases the difference might
be just a display of a different legal notification. In other cases there
might be additional features for users from a certain origin and reduced
features for other.

Number 2 above would naturally make the session struct quite large if
the longest possible local path name would have to fit in for LOCAL
domain origins. OTOH that increase would not cause a serious memory load
because there is only one session struct shared by all processes within
a session. From my point of view such relatively small sacrifice in memory
would be quite reasonable.