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