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@xxxxxxxxxx> 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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
