/etc/security/audit_warn -- where to log to by default?

[fergus]

On 26.01-12:10, Robert Watson wrote:
[ ... ]
> The "problem" is that in the current UNIX world order, any application
> running with any credential can submit a log message, in most systems
> using a single datagram UNIX domain socket.  Likewise, that we have a
> unified set of system logs combining log messages from all applications. 
> We can break these invariants, or we can try and maintain them.  If we
> break the unified logging model, we still have to come up with a coherent
> notion of how to handle applications from different security domains
> submitting, so while that may eliminate some of the issues, we still have
> to address the rest.
> 
> I think so far we've identified a few possible approaches of interest that
> address various parts of the problem.
> 
> - In a world with only an MLS policy, there isn't really a problem,
>   because write up is permitted, and you can run the system log daemon at
>   system high.  However, many trusted systems will make use of at least
>   one additional policy type, an integrity policy, in order to protect the
>   TCB. 
> 
> - In a world with additional or different policies, such as an integrity
>   policy or a configurable policy, provide syslogd with additional
>   privileges/rights so that it can receive communications from processes
>   with a variety of levels/grades/domains/...  Depending on the model,
>   this privilege/right might be required solely to create the UNIX domain
>   socket that the log messages will be submitted on.  For example, in a
>   Biba policy, to set the label on the socket -- after that, the privilege
>   could be released.  Because communication is one-way, some exposure is
>   limited.  However, since syslogd will be processing messages from quite
>   untrusted sources, we'd want to be very careful.  Also, specifying the
>   nature of the exception on the socket will be important: our current
>   equal label in MLS/Biba is probably too broad, since it may connote
>   other rights than "connect/send".  With Type Enforcement, it's possible
>   to specify "just connect/send", so that is not such a problem.
> 
> - If we want label-differentiated logging, there are a couple of
>   approaches.  In a world with relatively few labels (low, medium, high),
>   poly-instantiation of the logging daemon, socket, and log files would
>   provide strong separation without providing additional privilege.  In
>   practice, this will scale poorly to larger numbers of labels, requiring
>   syslogd to be substantially aware of the labels in use, how to classify
>   log messages, and if we want it to log to log files of different labels,
>   may require syslogd to continue to run with substantial privilege.  One
>   reason to want this sort of support, though, is to make it possible for
>   a privileged process to differentiate between an unprivileged non-TCB
>   login process logging events from a privileged one -- specifically,
>   today's syslog allows any process to submit any log message they want
>   with any logging characteristics.  This is arguably undesirable in a
>   more tightly controlled system.
> 
> In the short term, the first and second answers are "easy", but for some
> policies incomplete.  The third answer provides much more control, as well
> as improving the safety of the log messages themselves, but at the risk of
> providing more privilege to syslogd, which also happens to be exposed to a
> fair amount of nasty material.  Regardless of what approach is actually
> used, it's immediately clear that syslogd will be a "weak link" in that it
> will be exposed to some potentially hazardous input, and needs careful
> review.  In particular, it should not be quite un-vulnerable to attacks
> such as buffer overflows, but also against denial of service scenarios
> where less privileged applications might consume syslogd resources to the
> exclusion of more privileged applications, perhaps causing the loss of log
> messages from the TCB.

whilst i understand, i would suggest that we are talking about
degrees or stages of implementation.  for the immediate term i
would agree that MLS write-up (or equivilant) would suffice.
where we have greater degrees of seperation (e.g. you want to
have integrity beyond that) poly-instantiation (i think
i understand the term) is available.

i do not realistically see need beyond this.  in my experience
getting any degree above discresionary control is more than
enough from a client perspective and takes a good deal of effort.
thus the higher grade stuff you are talking about will be a
very long time coming.

conceptually i think there will always be a need to pass
messages and share access between different labels - no matter
the security model.  if that is prohibited by design then i
think the implementation of a common syslogd is directly
conflicting.  i would, personally, be against such contradictory
ideas.  that is to say - if i implement a security policy that
explicitly prohibits messages being passed between distinct
labels then it is implicit that i cannot use a common logging
facility.  my point being that MLS has facility to do this and
pitbull LX (the only other system i know) has greater facility
to do so - if you choose something more restrictive you
probably don't want this to happen.

i also fail to see the need for syslogd to have privilage, or
even substantial access, even when talking about the facilities
you mentioned.  unless you want syslogd to be able to directly
log to files with _any arbitary_ label - even TCB?.  that sounds
like very poor design whatever features you implement to
mitigate it.

logging the label sounds good but i would expect that the daemon
would do that transpantly by pulling the label from a kernel
struct associated with the actual message (obviously for UDP
or other network traffic this will require CIPSO or something).
it is then a case of modifying the syslogd.conf to understand
labels add the ability to log based on that. e.g:

==
# $TrustedBSD: src/etc/syslog.conf,v x.xx.x.x xxxx/xx/xx xx:xx:xx ttw Exp $
security.*[LABEL_A]					/var/log/LABEL_A/security
==

note, the daemon would not need to parse any untrusted input
until after it have changed it's label - thereby restricting
damage to a label the sending process already has access to.

not sure the above explanation is entirely clear but it's the
best i can manage.

-- 
: fergus cameron                :   [ .]        cobbled    :
: ^^^^^^@cobbled.net            : [ ~][ ]             .net :

To Unsubscribe: send mail to majordomo at trustedbsd.org
with "unsubscribe trustedbsd-discuss" in the body of the message