[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Security Implications of running startx from command line - was Re: Startx: was Great Debian experience



On 2014-03-21 17:13:41 +0100, Gian Uberto Lauri wrote:
> Vincent Lefevre writes:
>  > The fact that it is multi-user doesn't mean that it will necessarily
>  > be used by several desktop users.
> 
> You can remove spawning the getty on tty you don't want to use.
> 
> I don't know how to do this with systemd... With init you had some
> nice and well commented entries in /etc/inittab
> 
> The multiple console is a feature dating back when there was no X11
> available for GNU/Linux...

Note that I do *not* want to remove the multiple console feature.
It is useful even when there is a single user.

>  > I suppose that users who use startx haven't installed a display manager.
>  > So, I think that the feature should be enabled only when a display
>  > manager is running.
>  > 
>  > Actually even better: if user A has locked his X session, then
>  > the system should prevent any switch to a Linux console where
>  > A has logged in.
> 
> This would be nice, but I think is sort of an hell... 
> 
> When the user presses the magic sequence, the one in charge of
> switching tty should pick the process table, identify X and a possible
> screen saver (how? I could use a custom written screensaver called
> ullabagulla), then identify which the parent process of X and see
> which tty it belongs to, and block any attempt to switch to that tty.

Perhaps the kernel should have a new feature that could be used
for tty switching permissions.

> AFAIK Ctrl+Alt+F1 trows a trap, therefore all the stuff above has
> to run in kernel space...

Yes, except that...

> A safer solution should be to remove all the getty except one. But
> these tty are useful to recover a system in bad times...

Even "remove all the getty except one" is not safe, because the
problem is precisely the tty where the user has logged on and run
startx.

Now, the X-locking process could still remap the keyboard to remove
all these XF86Switch_VT_* from the mappings, so that I suppose that
tty switching would no longer be possible, and restored the settings
at the end. And perhaps it can do this selectively, i.e. only do
this for tty's where the user has logged on.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Reply to: