Riny Qian wrote: > > Darren J Moffat wrote: >> Riny Qian wrote: >> >>> All, >>> >>> Please take a look at the updated virtual console spec: >>> >>> http://www.opensolaris.org/os/project/vconsole/vconsole-spec.txt >>> http://www.opensolaris.org/os/project/vconsole/vt.7i.txt >>> >>> Any comments are welcome. >> >> DJM-1 2.6 /dev/console & root login >> >> I'm not sure you can allow root login on /dev/console >> and on /dev/vt#. The /etc/default/login variable CONSOLE >> only specifies a single device and I'm not sure I'm comfortable >> with /dev/console meaning /dev/console and all of /dev/vt. >> >> However I do see possible value in allowing local root >> logins on multiple vts, so I'll need to think more about >> this. > > Since we trust it on /dev/console, we should trust it on /dev/vt#. > Otherwise it would be inconvenient in practice.
I don't think that necessarily follows, consider this case. /dev/console could, I believe, be a serial line. That means that the console could be in a physically separate location to the usb attached keyboard/mouse and the monitor. In that case it may not be desirable that root can login on the /dev/vt# entries but we would accept it on /dev/console since that is the serial line. My concern is with CONSOLE=/dev/console suddenly starting to mean /dev/console and all the allocated /dev/vt# entries. Now in my opinion CONSOLE= is actually the wrong interface here. On at least one Linux system I've seen they do this check in a PAM module (where we should be doing it) and it checks a file /etc/securetty. That file has listed in it all of the /dev entries that root may login on. I notice on CentOS that vc/1 etc are listed. Now I don't think this case should need to fix the problem we have with login(1) being the place we do the CONSOLE= check, nor do I think this case needs to ship a PAM module to replace that. What we do need to agree on though is if /dev/console should continue to mean just /dev/console or should it mean /dev/console and all /dev/vt# devices. Personally I prefer that it say meaning just /dev/console and that some other case fix login(1) and introduce the appropriate PAM module to allow root to login on other devices. Which brings up another question why are we naming the device /dev/vt# when Linux is naming them /dev/vc/# ? Any reason to be different here ? >> DJM-2 2.7.2 ACLs for usb etc devices >> >> Are you saying that if user "bob" logins in on vt1 and >> user "alice" logins on vt2 then there will be an ACL of >> both of them on the audio and usb devices ? > > Right. Actually at the begining, we wanted to group > all these devices (add a console group in the system, > and dynamically add/remove the logged in user into > the console group upon logging in/out. But ACL seems > better than group, so we chose ACL. [it was recommeded > by Casper Dik.] I agree that an ACL is much better than using a group. However see below for what appears to be a TX and device allocation interaction. >> I don't think this is a good idea. I'm also concerned >> about how this interacts with device allocation and >> Trusted Extensions. > > We don't see any impact on the device allocation > and Trusted Extensions. What label are the vt devices running at when TX is enabled ? What happens in this (on TX) case: User bob logs in graphically with gdm/dtlogin and allocates the audio device. This means that the audio device should only able available to bob. Now User alice does a login to /dev/vt2, from what you said above there would be an ACL added for Alice even though the device is owned by bob because allocate(1M) changed the ownership. That seems wrong and completely counter to the whole purpose of device allocation. So I believe you do have interaction with device allocation. At least based on the documentation you have provided, or some how it isn't clear to me how this works with device allocation. >> Please ask the security community to review this whole >> proposal for possible interactions with Trusted Extensions. >> > > Right. We talked it with people who're working Trusted Extensions > before, and they don't have any issue. But since we changed > the spec, we should communicate with them again. So what was the answer about the label of the vt devices ? Was it that they are ADMIN_LOW (or maybe ADMIN_HIGH) and the TX PAM modules ensure that users can't login ? If so that sounds okay. However that would mean that /dev/vt# is part of the Trusted Path I think. I'm not sure that is desirable in all cases. >> DJM-5 2.10 kmdb >> >> I expected that kmdb and panic would not be displayed >> on the current vt but only on the console and that you >> would still be able to switch to the console to interact >> with kmdb. However I think this mode might be acceptable >> and even desirable in some cases. > > We discussed it with kmdb guys before, and they don't want > to see kmdb is aware of virtual console and the switch. Okay. >> DJM-6 2.12 Xorg >> >> What about Xsun since that is still used on SPARC. > > There's no change to Xsun. > >> DJM-7 General >> >> Is the ioctl interface compatible with that on any other >> platform or is it unique to OpenSolaris systems ? > > compatible. So if the ioctl interface is compatible with Linux it seems to me that we should also be using /dev/vc/# as the device names. Using a subdir seems more like what Solaris would do here, eg /dev/pts/7 /dev/term/a. IIRC the /dev/tty* devices are SunOS 4.x compatibility names only. -- Darren J Moffat
