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

[Ilmar S. Habibulin]

On Tue, 25 Jan 2005, Adam C. Migus wrote:

> The problem I see with this approach is that by allowing syslogd (a
> userland process) to process messages from different levels and to
> change it's own level, you are violating the standards and principles of
> the architecture you're trying to implement.  As an alternative is it
I don't think so. kernel has no label, but it manages labeled data, having
access to anything. syslogd can't have no label, because it is userland
process. And it must manage/process labeled data with different labels. So
lets make it trusted process, which helps us to enforce our security
policy. Why not?

> possible to run multiple syslogd daemons, each reading from a different
> /dev/log where the log device, the syslogd and the processes logging to
> it all have the same label?
You said multiple -- how much is enough? IMHO this is the main problem.
Such an approach can be implemented, using MLD concept. But i think of
this as an administrator mightmare. Just imagine, if every user has the
same level and different compartment. And they are calling su/login. Do
you need <the number of compartments or compartment combinations> logs and
syslogd processes?

> >There is many problems with logs, for example, utmp,wtmp and lastlog
> >filled by login. And what about X Server? I can make it run on MAC
> >environment, but first of all i need to unsecure :( it by setting
> >"*/equal" to /dev/io, /dev/mem and some other devs.
> >There is many problems with developing trusted os with classic mandatory
> >access controls, and i some times wonder is there anybody really needs
> >such functionality.
> Would the approach above work to help solve these problems as well?
You mean setting equal labels on logfiles/logsockets of syslogd? This is
unsecure.

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