From: Frank Benkstein <frank-lkml@benkstein.net>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: VT_PROCESS, VT_LOCKSWITCH capabilities
Date: Wed, 01 Aug 2007 11:53:27 +0200 [thread overview]
Message-ID: <46B05817.5070305@benkstein.net> (raw)
In-Reply-To: <20070731214931.8d05f367.akpm@linux-foundation.org>
Andrew Morton wrote:
> On Wed, 01 Aug 2007 00:22:38 +0200 Frank Benkstein <frank-lkml@benkstein.net> wrote:
>
>> I wonder why there are different permissions needed for VT_PROCESS
>> (access to the current virtual console) and VT_LOCKSWITCH
>> (CAP_SYS_TTY_CONFIG).
>>
> Perhaps the issue with VT_LOCKSWITCH is that its effects will persist after
> the user has logged out? So user A is effectively altering user B's
> console, hence suitable capabilities are needed?
>
> Is the current code actually causing any observable problem?
Both controls can be used to deny service to other users. For example:
user B locks his X session or current console and walks off to lunch.
User A walks up to user B's machine, switches to another console, logs
in and execs program_that_does_vt_process. User B will not be able to
continue work unless he/she can get user A or someone with CAP_KILL to
kill the program. If remote logins aren't allowed, the only way I see
to use the machine again is to reboot.
I think VT_PROCESS (or VT_SETMODE respectively) should be protected with
the same level of security as VT_LOCKSWITCH, i.e. CAP_SYS_TTY_CONFIG.
prev parent reply other threads:[~2007-08-01 9:53 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-31 22:22 VT_PROCESS, VT_LOCKSWITCH capabilities Frank Benkstein
2007-08-01 2:44 ` Frank Benkstein
2007-08-01 22:19 ` Andrew Morton
2007-08-02 10:31 ` Frank Benkstein
2007-08-01 4:49 ` Andrew Morton
2007-08-01 9:53 ` Frank Benkstein [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46B05817.5070305@benkstein.net \
--to=frank-lkml@benkstein.net \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.