On Sunday 24 January 2010 02:20:54 pm Stephen John Smoogen wrote:
>> 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).
I guess you mean read permissions for syslog. There are definitely things there
that unprivileged users should not have access to.
> 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.
True. They should not be able to do that. They can use logger and fill it up
and thus logrotate will take care of that for you.
> 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?
Yes and the point of auditing is to catch people abusing the system. When I
start into the next phase of audit system work, I will fix it so the admin can
have those people logged out and their account locked if so desired.
> [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?
We do not set it that way because you could get a flood of AVCs (due to
something like having the wrong label on a bunch of freshly imported files)
that would then take your system down.
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.
Its not in any security guides we've worked on, because its already defined by
the file permissions and capability checks that the kernel does. We never
advise people to weaken security by overriding the defined rules. We normally
tell people how to make it more restrictive depending on their threat model.
When anyone is able to exceed the defined permissions, there is typically
implied audit requirements, too. Any changes to system access policy must be
auditable. If its file permissions being changed, we can audit that from the
kernel. If there is a "policy database", then we need more that just file
access auditing, but exactly what was changed inside the file. This is why we
had to patch shadow-utils and password for Common Criteria.
So, if there is any "policy database", it must have an editor to configure it
and it must have auditing built in, and the audit events must be searchable by
the audit utilities, and changes must be attributed to the user making them
and they must be traceable to the login session. If the "policy database" is
consulted by something that increases privileges or denies them, then the
access decisions must be auditable on demand. This is why we patched pam.
So, please consider audit requirements that a priv escalation system will
require.
-Steve