[vconsole-discuss] help review updated virtual console spec
Darren J Moffat wrote: > Riny Qian wrote: > >> >> >> Darren J Moffat wrote: >> >>> Casper.Dik at Sun.COM wrote: >>> >>> >>> Which I take to mean do not update /etc/logindevperm with >>> /dev/vt/# entries so that login on a VT doesn't get changes to >>> any of the devices. >>> >>> That at least means this project doesn't make things any worse >>> than they already are. >>> >> >> Or maybe we can do it the same way as Linux does: only the first >> non-root logged in console user owns these devices. It seems fine >> since there's only one account that will really use these devices >> in most cases. > > > That seems reasonable though I don't like the special casing of root. Finally, now, we change it back to our initial proposal: only the first logged in console user, either root or non-root, owns these devices. thanks, Riny
[vconsole-discuss] help review updated virtual console spec
Darren J Moffat wrote: > Casper.Dik at Sun.COM wrote: > > > Which I take to mean do not update /etc/logindevperm with > /dev/vt/# entries so that login on a VT doesn't get changes to > any of the devices. > > That at least means this project doesn't make things any worse > than they already are. > Or maybe we can do it the same way as Linux does: only the first non-root logged in console user owns these devices. It seems fine since there's only one account that will really use these devices in most cases. Though, I'm inclined to give all console users permission to access these devices via ACL, which is a simple and effective solution.
[vconsole-discuss] help review updated virtual console spec
Darren J Moffat wrote: >>So it seems that our ACL proposal for other console devices in >>/etc/logindevperm is fine, and it does not introduce any regression. > > > What your proposal does is allow multiple people access > to the device at the same time. That isn't possible today. > > I believe that makes it worse because now you have the > potential for them both to be trying to use the device > at the same time. > I think that allocate(1) is mostly used in TX to manage audio like devices, where /dev/audio is commented out in /etc/logindevperm. On normal systems without TX, allocate(1) is not used, instead, logindevperm(4) is used to manage all console devices. So IMO, it seems no problem for our proposal, though I agree that makes somewhat worse.
[vconsole-discuss] help review updated virtual console spec
Riny Qian wrote: > > > Darren J Moffat wrote: >> Casper.Dik at Sun.COM wrote: >> >> >> Which I take to mean do not update /etc/logindevperm with >> /dev/vt/# entries so that login on a VT doesn't get changes to >> any of the devices. >> >> That at least means this project doesn't make things any worse >> than they already are. >> > > Or maybe we can do it the same way as Linux does: only the first > non-root logged in console user owns these devices. It seems fine > since there's only one account that will really use these devices > in most cases. That seems reasonable though I don't like the special casing of root. However that suggests a non trivial rewrite of how logindevperm works today and still doesn't solve the allocate problem - yes this project didn't create the allocate problem but if you use ACLs rather than ownership change you are making it worse. > Though, I'm inclined to give all console users permission to access > these devices via ACL, which is a simple and effective solution. NO this is a security hole worse than what already exists today which is device stealing (stealing the microphone is a problem, stealing the audio out will probably cause the current output to stop). -- Darren J Moffat
[vconsole-discuss] help review updated virtual console spec
Riny Qian wrote: > > Darren J Moffat wrote: > >>> So it seems that our ACL proposal for other console devices in >>> /etc/logindevperm is fine, and it does not introduce any regression. >> >> What your proposal does is allow multiple people access >> to the device at the same time. That isn't possible today. >> >> I believe that makes it worse because now you have the >> potential for them both to be trying to use the device >> at the same time. >> > > I think that allocate(1) is mostly used in TX to manage audio like > devices, where /dev/audio is commented out in /etc/logindevperm. On > normal systems without TX, allocate(1) is not used, instead, > logindevperm(4) is used to manage all console devices. So IMO, it seems > no problem for our proposal, though I agree that makes somewhat worse. Not at all. allocate(1M) is a standard part of Solaris and works just fine without TX. It has been in Solaris for many many releases now. I really don't believe it is acceptable to make it any worse than it already is. The current situation is at a least some what "safe" because even when logindevperm steals a device from a user it only gives it to one other user. While there is a risk with this (microphone in particular) it is less than what your proposal does which is gives ACLs so that access could be shared. I believe that when this is ARC reviewed we will end up having advice in the opinion that another project needs to be created to clear up this mess - probably in a way similar to what Casper described in his email. -- Darren J Moffat
[vconsole-discuss] help review updated virtual console spec
Darren J Moffat wrote: >>>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. Currently (without virtual console), both logindevperm(4) and allocate(1) are not aware of each other (even non-TX): Rlogin to a system on which nobody has logged in; allocate audio device to Bob, then Bob will own the audio device ( BSM is enabled); Then Alice logs in on the system console, and Alice owns the audio device; When Alice exits, the audio device is owned by root. And when the system is labed in TX, all the devices in /etc/ logindevperm will not be allocatable any more. So in TX, /etc/ logindevperm can be empty, and all these console devices can be managed by allocate(1) by the system administrator. In fact, as long as there's more than one program managing these devices, there's conflict. So it seems that our ACL proposal for other console devices in /etc/logindevperm is fine, and it does not introduce any regression.
[vconsole-discuss] help review updated virtual console spec
Casper.Dik at Sun.COM wrote: > For now, it seems that the only thing we deal "properly" with is > the "screen". > > Security does not allow sharing of any of the input devices (keyboard, > mouse, audio) but because multiple sessions coexist we cannot > revoke the access, even if we had the mechanism to do so. yep. > > For the audio device, this is much more difficult: > > - device allocation does not solve this because it only gives > one concurrent user access and it calls 'fuser -k' on > running processes in other sessions > > - Windows is also broken as it allows all sessions to continue > to stream output (as far as I can tell); is this something we > want to emulate (well, Darren said he liked playing iTunes in > one account while doing something else in another account, yet > this seems wrong on general principle to me) That was on MacOS X (I don't do Windows) and it doesn't appear to work anymore - can't remember when it stopped working or if it was an iTunes or OS upgrade that changed the behaviour. > - the input of the audio device (eaves dropping, who remembers > the "rsh hostname cat /dev/audio" scare?? Remember it, not only that I used it (for fun when a student!). > This sort-of screams for a "session aware" audio mixer. Hmn, now aren't we having that same discussion on an internal Sun list at the moment with respect to Sun Ray audio! > > There is, of course, another solution: PUNT. Which I take to mean do not update /etc/logindevperm with /dev/vt/# entries so that login on a VT doesn't get changes to any of the devices. That at least means this project doesn't make things any worse than they already are. > Just assume that it's always the same physical user who is using > different sessions so leakage is not an issue. But if this is > acceptable, then we must have a secure attention key: > > - KILL ALL VT SESSIONS using a key sequence which cannot be > disabled by programs, revoking all session I/O devices and > resetting all ACLs, giving a clean "/dev/console" login. > Such a secure attention key combination is long overdue anyway, but Ineed but I'm not sure this project should be given the task of providing it. -- Darren J Moffat
[vconsole-discuss] help review updated virtual console spec
I've updated the spec according to your comments. Changes include: . Alt+F1 for the system console; . select /dev/vt/# for virtual console device names; . console-login service is extended, instead of adding a new vconsole-login service; . /dev/console for CONSOLE in /etc/default/login does not include virtual consoles; thanks, Riny 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. > >
[vconsole-discuss] help review updated virtual console spec
>I believe that makes it worse because now you have the >potential for them both to be trying to use the device >at the same time. The more I think of this the more it seems we need some form of generic device multiplexing layer. The devices we are multiplexing are: input: - keyboard - mouse output: - screen input/output - audio For now, it seems that the only thing we deal "properly" with is the "screen". Security does not allow sharing of any of the input devices (keyboard, mouse, audio) but because multiple sessions coexist we cannot revoke the access, even if we had the mechanism to do so. For keyboard/mouse, there are some proposed solutions: - prevent output when session mismatches - revoke access currently given through /etc/logindevperm and trust Xorg/Xsun not to read from the devices. where the second solution has some clear advantages (ease of implementation) For the audio device, this is much more difficult: - device allocation does not solve this because it only gives one concurrent user access and it calls 'fuser -k' on running processes in other sessions - Windows is also broken as it allows all sessions to continue to stream output (as far as I can tell); is this something we want to emulate (well, Darren said he liked playing iTunes in one account while doing something else in another account, yet this seems wrong on general principle to me) - the input of the audio device (eaves dropping, who remembers the "rsh hostname cat /dev/audio" scare?? This sort-of screams for a "session aware" audio mixer. There is, of course, another solution: PUNT. Just assume that it's always the same physical user who is using different sessions so leakage is not an issue. But if this is acceptable, then we must have a secure attention key: - KILL ALL VT SESSIONS using a key sequence which cannot be disabled by programs, revoking all session I/O devices and resetting all ACLs, giving a clean "/dev/console" login. Such a secure attention key combination is long overdue anyway, but As all of the affected devices are STREAMs devices, a generic "itsmine" streams module (unpoppable) may suffice. This does require the keyboard/mouse opens to be clone opens which duplicate output to all processes opening it. (So "cat /dev/mouse" will no longer steal mouse input but will rather mirror it) Casper
[vconsole-discuss] help review updated virtual console spec
Riny Qian wrote: > > Darren J Moffat wrote: > 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. > > > Currently (without virtual console), both logindevperm(4) and > allocate(1) are not aware of each other (even non-TX): > Rlogin to a system on which nobody has logged in; allocate > audio device to Bob, then Bob will own the audio device ( > BSM is enabled); Then Alice logs in on the system console, > and Alice owns the audio device; When Alice exits, the audio > device is owned by root. I agree that this is a current problem. Bob just looses access to the device he had allocated and Alice gets it instead for the duration of her login. > In fact, as long as there's more than one program managing these > devices, there's conflict. Agreed. > So it seems that our ACL proposal for other console devices in > /etc/logindevperm is fine, and it does not introduce any regression. What your proposal does is allow multiple people access to the device at the same time. That isn't possible today. I believe that makes it worse because now you have the potential for them both to be trying to use the device at the same time. -- Darren J Moffat
[vconsole-discuss] help review updated virtual console spec
Darren J Moffat wrote: > Riny Qian wrote: > > >>What if we do extend /dev/console meaning to include >>/dev/console and all /dev/vt# devices in this case, >>and will do that fix in later case? Is there any impact? > > > There could be but it depends on who the future case > is done. > > I would rather not overload the string "/dev/console" > to mean /dev/console and any /dev/vt#. Okey, I take that back, and still keep that /dev/console just means the system console. I'll update the spec soon. > > What is your timescale for integration of this project ? > Maybe I can at least get a design for fixing this > area of Solaris ARC approved before your case is approved. > ARC can then decided if it is important that you depend > on it or not. >
[vconsole-discuss] help review updated virtual console spec
Darren J Moffat wrote: > Riny Qian wrote: > > >>What if we do extend /dev/console meaning to include >>/dev/console and all /dev/vt# devices in this case, >>and will do that fix in later case? Is there any impact? > > > There could be but it depends on who the future case > is done. > > I would rather not overload the string "/dev/console" > to mean /dev/console and any /dev/vt#. > > What is your timescale for integration of this project ? The current plan is April next year if everything goes well. > Maybe I can at least get a design for fixing this > area of Solaris ARC approved before your case is approved. > ARC can then decided if it is important that you depend > on it or not. > > >>>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 ? >>> >> >>No, Linux is using /dev/tty#. (/dev/vc/# is for some >>other purposes.) > > > Ah okay, either way why aren't we using a subdirectory ? > > >>>IIRC the /dev/tty* devices are SunOS 4.x compatibility >>>names only. >>> >> >>We thought /dev/vt# would be compatible with Linux, and >>is simpler than /dev/vc/#. > > > But you said above Linux is using /dev/tty# so /dev/vt# is > not compatible with Linux. I also don't see how > /dev/vt# is simpler than /dev/vc/# or /dev/vt/#, and simpler > for whom ? Since Solaris already uses /dev/pts/ and /dev/term > I think this project really should use one of the following: > /dev/vc/# > /dev/vt/# > /dev/vterm/# > /dev/term/vt# > > I have no strong preference for any of those but I > do have a strong preference for using a subdir rather than > dropping the new devices directly in /dev/. > Looks reasonable. Okey, we'll change to /dev/vt/# if there's on opposition.
[vconsole-discuss] help review updated virtual console spec
Darren J Moffat wrote: >>>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. TX does not allow users to log in via console and virtual consoles. > > That seems wrong and completely counter to the whole > purpose of device allocation. The changes to logindevperm should be independent on allocate(1M). > > 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. > Any way, we'll look further and communicate with TX guys in security community.
[vconsole-discuss] help review updated virtual console spec
Darren J Moffat wrote: > 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. > What if we do extend /dev/console meaning to include /dev/console and all /dev/vt# devices in this case, and will do that fix in later case? Is there any impact? > > 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 ? > No, Linux is using /dev/tty#. (/dev/vc/# is for some other purposes.) >>>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. > We thought /dev/vt# would be compatible with Linux, and is simpler than /dev/vc/#.
[vconsole-discuss] help review updated virtual console spec
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. > > 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 ? > > I don't think this is a good idea. I'm also concerned > about how this interacts with device allocation and > Trusted Extensions. > > Please ask the security community to review this whole > proposal for possible interactions with Trusted Extensions. > As we discussed with Trusted Extensions group before, they said there is no user login on console in a full configured Trusted Extensions system, including root who will work like a role. So the change for /etc/logindevperm will not affect their system. Anyway, we will send them the latest spec for review. > DJM-3 2.8 SMF Service > > As per my previous emails I believe that the /dev/vt# > devices should just be instances of console-login and you > should not need a separate vconsole-login even due to > Zones. > > DJM-4 2.9 tipline > > How does this interact with consadm(1M) ? > > 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. > > DJM-6 2.12 Xorg > > What about Xsun since that is still used on SPARC. > > DJM-7 General > > Is the ioctl interface compatible with that on any other > platform or is it unique to OpenSolaris systems ? > > >
[vconsole-discuss] help review updated virtual console spec
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. > > 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 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. > > 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. > DJM-3 2.8 SMF Service > > As per my previous emails I believe that the /dev/vt# > devices should just be instances of console-login and you > should not need a separate vconsole-login even due to > Zones. If no other impact, we'll change to it. > > DJM-4 2.9 tipline > > How does this interact with consadm(1M) ? I don't see any impact here. > > 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. > > 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.
[vconsole-discuss] help review updated virtual console spec
Alan Coopersmith wrote: > Darren J Moffat wrote: >> /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. > > So should a new name be introduced that means /dev/console and > all /dev/vt*'s? Say /dev/vt* or /dev/vc/* ? > >> 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's what BSD's use too isn't it? NetBSD uses a PAM module of the same name as RHEL, pam_securetty. but uses /etc/ttys and looks for the secure token. >> 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. > > Moving it into PAM would reduce one of the reasons other > code calls libcmd to read /etc/default/login (it's not just > login - it's also xdm, gdm, & dtlogin), which is also a good > thing. See my proposal in my other email message cc'd to this list and sent to security-discuss. -- Darren J Moffat
[vconsole-discuss] help review updated virtual console spec
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. thanks, Riny
[vconsole-discuss] help review updated virtual console spec
Riny Qian wrote: > >> What happens in this (on TX) case: That was supposed to say non TX. Device allocation works without TX it is a standard Solaris feature. > TX does not allow users to log in via console and virtual > consoles. Yes but that isn't relevant to the example I gave since device allocation is a standard Solaris feature that doesn't need TX. I agree though that with TX enabled normal users won't be able to login on the console or virtual consoles anyway since they have a label outside of the users clearance. >> That seems wrong and completely counter to the whole >> purpose of device allocation. > > The changes to logindevperm should be independent on > allocate(1M). I don't see that they are because with your project adding an ACL to the device, say the audio device. How is it ensuring that the device isn't already allocated with allocate(1M) to an end user ? > Any way, we'll look further and communicate with TX guys in > security community. Thanks. -- Darren J Moffat
[vconsole-discuss] help review updated virtual console spec
Riny Qian wrote: > What if we do extend /dev/console meaning to include > /dev/console and all /dev/vt# devices in this case, > and will do that fix in later case? Is there any impact? There could be but it depends on who the future case is done. I would rather not overload the string "/dev/console" to mean /dev/console and any /dev/vt#. What is your timescale for integration of this project ? Maybe I can at least get a design for fixing this area of Solaris ARC approved before your case is approved. ARC can then decided if it is important that you depend on it or not. >> 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 ? >> > > No, Linux is using /dev/tty#. (/dev/vc/# is for some > other purposes.) Ah okay, either way why aren't we using a subdirectory ? >> IIRC the /dev/tty* devices are SunOS 4.x compatibility >> names only. >> > > We thought /dev/vt# would be compatible with Linux, and > is simpler than /dev/vc/#. But you said above Linux is using /dev/tty# so /dev/vt# is not compatible with Linux. I also don't see how /dev/vt# is simpler than /dev/vc/# or /dev/vt/#, and simpler for whom ? Since Solaris already uses /dev/pts/ and /dev/term I think this project really should use one of the following: /dev/vc/# /dev/vt/# /dev/vterm/# /dev/term/vt# I have no strong preference for any of those but I do have a strong preference for using a subdir rather than dropping the new devices directly in /dev/. -- Darren J Moffat
[vconsole-discuss] help review updated virtual console spec
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
[vconsole-discuss] help review updated virtual console spec
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. 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 ? I don't think this is a good idea. I'm also concerned about how this interacts with device allocation and Trusted Extensions. Please ask the security community to review this whole proposal for possible interactions with Trusted Extensions. DJM-3 2.8 SMF Service As per my previous emails I believe that the /dev/vt# devices should just be instances of console-login and you should not need a separate vconsole-login even due to Zones. DJM-4 2.9 tipline How does this interact with consadm(1M) ? 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. DJM-6 2.12 Xorg What about Xsun since that is still used on SPARC. DJM-7 General Is the ioctl interface compatible with that on any other platform or is it unique to OpenSolaris systems ? -- Darren J Moffat
[vconsole-discuss] help review updated virtual console spec
Darren J Moffat wrote: > /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. So should a new name be introduced that means /dev/console and all /dev/vt*'s? Say /dev/vt* or /dev/vc/* ? > 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's what BSD's use too isn't it? > 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. Moving it into PAM would reduce one of the reasons other code calls libcmd to read /etc/default/login (it's not just login - it's also xdm, gdm, & dtlogin), which is also a good thing. -- -Alan Coopersmith- alan.coopersmith at sun.com Sun Microsystems, Inc. - X Window System Engineering
