Initial draft of privilege escalation policy

Stephen John Smoogen smooge at
Sun Jan 24 19:20:54 UTC 2010

On Sat, Jan 23, 2010 at 6:19 PM, Stephen John Smoogen <smooge at> wrote:
> On Sat, Jan 23, 2010 at 4:58 PM, Steve Grubb <sgrubb at> wrote:
>> On Wednesday 20 January 2010 01:50:21 pm Stephen John Smoogen wrote:
>>> >> * Write to system logs (with the exception that the 'cause to be
>>> >> performed' provision is waived in this case)
>>> >
>>> > Huh ? The mere fact of me logging in will cause system logs to be
>>> > written...
>>> You are not writing directly to /var/log/messages. You log in and
>>> login sends a message to syslogd which writes to the log.
>> Syslog has *no* integrity guarantees, only the audit logs do. Any user can run
>> the /usr/bin/logger program and flood syslog. You can also call openlog() and
>> tell it you are the kernel. Syslog is worthless from a security PoV.
> I was talking a different type of integrity (i think it is integrity).
> A user might be able to run logger over and over but a user can not
> 'cat /dev/null > /var/log/messages' and have it null the file out.
> Couldn't even the audit logs be 'played' with in a default system by
> running a program that hit a couple of rules over and over again?
> [Well I think it would used to because of a bad rule I once crafted to
> watch access to /etc/shadow and a program that checked to see if the
> file had been changed.]  Yes audit and the kernel can be set up to
> shut down the system if it fills but in the default system is that the
> case?

Sorry.. my email yesterday was rather grumpy.  Isn't there a general
security outline for what a non-priveledged Unix user can and can not
do on a system in one of the various security guides? If the work has
been done before, we should use that.

Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning

More information about the test mailing list