Kyle McDonald wrote: > Aaron Zang wrote: >> >> There are actually other reasons that we want to get rid of root unlock, >> as stated as reason #2 and #3. The Xsession lock is just one aspect. >> >> A more serious problem that can be resulted from root unlocking is that >> root user can unlock a normal user's console and get this normal user's >> attribute without any record. Of course, root user can always do this >> by "su", >> but the "su" could be audited if audit is enabled. >> Whereas in our case, the right way to do audit is to set up audit >> context >> from the ucred of the process running on the virtual console being >> unlocked. >> If we allow root unlock, and we want to record this behavior, we have to >> make up a fake root audit context, and this is really a very bad >> thing to do >> and is not a correct behavior as allowed by audit. >> The above may explain "It can also lead to incorrect attribution of >> actions >> to the locking user by another user." as stated in reason #2. >> >> > When Running large computer labs at universities, this root-unlock > feature has been a godsend for when users lock their terminals and > leave the lab, and there are no other workstations available for new > users. > If virtual console is enabled, there will be multiple virtual consoles providing both console login sessions and graphic sessions. Whoever locked *ALL* these sessions should be treated as malicious user and should be punished somehow.
> What if the only thing the root password could do was to unlock *and* > logout the session on that console. In other words they wouldn't be > allowed access to the running processes, they would just be returned > to the login prompt. > vtdaemon does console locking/unlocking on behalf of the console session being locked/unlocked. If we allow root to unlock the session, no matter it has restricted accessibility or not, we should audit this unlocking event. This will eventually result in faking a root audit context, and that is *not allowed* by SUN audit policy. > What I never liked was that it meant we needed to give the lab > proctors the root password to the lab workstations. > Maybe something could be done with with roles, profles, etc. for this? The project team believes that the accessibility to the local physical consoles should be managed properly. If a person is ever allowed to access the local console, he/she should be trusted to behave properly. Virtual consoles could solve by some degree the situation that a person *accidentally* locked several of the available virtual consoles, the system administrator could login via one of the rest of the available consoles and deal with the mess. But if all the available virtual consoles are locked out, what should be blamed is the management of physical access to the local consoles. -- aaron
