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

[Adam C. Migus]

fergus wrote:

>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.
>
>  
>
How about 1 syslogd process reading from multiple devices each with the 
appropriate label implemented as a common label-aware syslogd process 
that demonstrates the ability to read from multiple devices, each with 
it's own label but on the premis that before it reads the message from 
device with label X it creates a child with label X which is capable of 
processing the message(s) in question.

I'm not sure my explanation is any more clear but as I'm seeing it the 
approach borders on the limits of acceptability but does fulfill the 
requirements and minimizes concerns such as leakage and covert 
channels.  In that vain the only problem I see with the above mentioned 
implementation is the syslogd.conf file which provides a lot of 
information about labelling and logging for all labels.

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