Hi Garrett, Thanks for your suggestion. Actually we've thought about this idea during the very beginning of project design. The thing is which virtual console should be reserved for root use only. The system console (/dev/console) is not the possible choice, since it would change the behavior of the system console, it might be seen as a regression. And for the other virtual consoles, we actually allow to dynamic reconfig the available virtual console number. Even if the second virtual console /dev/vt/2 is chosen to only allow root login, there might be chances that the user re-configure it away. Of course a possible solution is to hard reserve 2 virtual consoles, but user might only want only one console session and only one graphic session.
Anyway, people can always disable the console locking feature of virtual console by setting the "secure" option of vtdaemon service to "false", if the chances that mis-behaved users messing up the consoles are very high. -- aaron Garrett D'Amore wrote: > A possible workaround/comprromise: > > What if there was one extra VT, that was only available to > administrators? Then a root user could always login, and if necessary > kill off the sessions holding the other VTs. This wouldn't break > auditing, and it wouldn't require the console keyboard and monitor to > be secured at all costs. (The usual concerns about BIOS access other > local access considerations still apply, of course.) > > -- Garrett > > > Aaron Zang wrote: >> 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 >
