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

[Robert Watson]

On Wed, 26 Jan 2005, fergus wrote:

> On 25.01-09:34, Ilmar S. Habibulin wrote:
> [ ... ]
> >                     What can we do with syslogd? Give it permission to
> > change its' own label. Set the label of /var/run/log to "*/equal". So
> > everybody can write to the log. Now syslog reads data and decides which
> > log it must be stored to. Then it changes own label to be equal to the
> > appropriate log and writes to it.
> 
> this would be very insecure.  the privilage your talking about (arbitary
> label switching) would basically give the box away. 

So here-in lies the dilema, and the answer would seem to lie somewhere
along a spectrum of possibilities, and based on requirements.

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.

Robert N M Watson


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