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

[Adam C. Migus]

Ilmar S. Habibulin wrote:

>On Tue, 25 Jan 2005, Robert Watson wrote:
>
>  
>
>>The primary interesting downside would be on a system running MAC, where
>>perhaps the integrity grade, confidentiality level, or domain/type of the
>>audit data is different from that of the other log data, and would benefit
>>from being stored in another directory to facilitate that, not to mention
>>keeping the syslog daemon out of the loop (as syslogd talks to a lot of
>>other processes directly, including many untrusted ones).
>>    
>>
>Any system process/daemon talk to them. Maybe just kill 'em all? ;-)
>
>  
>
>>Any thoughts on this one?
>>    
>>
>I think that some sort of reengineering must be done to make system
>daemons act according to mandatory policies. Daemon must implement
>mandatory policies by controling information flows, sorting and labeling
>them appropriately. 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.
>
>  
>
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 
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?

>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.
>
>To Unsubscribe: send mail to majordomo at trustedbsd.org
>with "unsubscribe trustedbsd-discuss" in the body of the message
>  
>
Would the approach above work to help solve these problems as well?

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