Alan Cox wrote:
>> Security-sensitive upper layers like virus scanners and loggers
>> would want to do it that way. The upper layer might even just log
>> the fact that mount happened and then stay out of the way after that.
>
> What makes you say that. If the administrator has full priviledges then
> its kind of irrelevant trying to force anything "for security reasons"
Check out the NSA's guide for securing Win2k machines sometime. They
go through all kinds of steps to separate auditing and administration
even though an administrator can get around them and play with the audit
trail anyway. It raises the bar and removes the defense of plausible
deniability if an admin gets caught (he can hardly claim it was an
'accident' that he granted himself audit privileges and then used them
to tamper with the audit log.)
1. Create a new group: Auditors
2. Grant these rights to Auditors:
Take ownership of files; Manage auditing
3. Create a new user: Auditor, and put it in these groups:
Users; Auditors
4. Log on as Auditor and take ownership of
%systemroot%\system32\config\SecEvent.Evt
5. Set permissions on that security logfile:
a. System: full control
b. Administrators: no access
c. Auditors: full control
6. Now log on as an administrator and take away these rights:
a. from Administrators: Manage auditing
b. from Auditors: Take ownership of files
7. Enable these extra security options:
a. crash on audit failure
b. clear page file on shutdown
c. full privilege auditing
d. lots more...
After setting up auditing and ACLs (many pages of directions for that)
the audit duties are done by unprivileged users and administrators
cannot see or alter the audit trail.
Seems like a lot of useless work given that the admins can grant
themselves any rights they want, doesn't it?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:31 EST