Initial draft of privilege escalation policy

[Steve Grubb]

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