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

/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.


>> 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

Reply via email to