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.
