Shortening email to what I wanted to reply to (agree ++ with the other parts.)
On Mon, Jan 25, 2010 at 7:45 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
> > [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.
Yeah.. I did that to a cluster once... my bad.
> 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.
I think what we are trying to define here is what the default system
is supposed to do. EG what is the standard 30+ year old default Unix
policy that people are supposed to expect. From that we can look at
what any escalation system is and how it should work.
Any escalation of privileges needs to be through methods that are
clearly and easily auditable.
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.
Personally I would prefer if we had just ONE system to do priv
escalation through. I wish there was some 'libsudo' or 'pamsudo' that
applications could go though then I would think your job, app writers
jobs and who knows else would be a lot easier. Either that or a sudod
but thats just crazy land.
--
Stephen J Smoogen.
Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning