TIOCCONS security revisited

TIOCCONS security revisited

[Julian Bradfield]

In August 2004, Olaf Dabrunz posted a patch, which appears to have got
into 2.6.10, restricting TIOC_CONS to CAP_SYS_ADMIN .

He justified this by claiming that normal users don't need to grab the
console output.

I disagree. Normal users log into the desktop of their machine, and
should expect to be able to see the console output just as much as if
they logged into "the console" and worked without graphics.
For example, I want to know when the machine I'm working on has
problems, when somebody is probing sshd, and simply when one of my
batch jobs wants to tell me something.

Further, on our systems, I own the console (ownership is transferred
to the user by the login procedure), so it's daft that I can't call TIOCCONS
on it.

I propose that a better security test would be:
user owns /dev/console OR has CAP_SYS_ADMIN .

It should then be the responsibility of the log-out procedure to
cancel redirections when it changes the ownership of devices back to
root.

In December '04, Lars posted about this breakage, and proposed a
simpler patch, allowing general TIOCCONS but restricting cancellation
(as per documentation), but I didn't see anything happen to this.

Any comments? If none, I'll propose a patch.

Re: TIOCCONS security revisited

[Jan Engelhardt]

>
>He justified this by claiming that normal users don't need to grab the
>console output.
>
>I disagree. Normal users log into the desktop of their machine, and
>should expect to be able to see the console output just as much as if
>they logged into "the console" and worked without graphics.
>For example, I want to know when the machine I'm working on has
>problems, when somebody is probing sshd, and simply when one of my
>batch jobs wants to tell me something.
>

By console I suppose you mean "printk output", because that's the only 
thing I can decipher from the 'redirecting stuff' in the TIOCCONS function. 
(Reminds me of klogconsole which is some sort of redirector.)

There is one slight problem with tioccons: if kernel output was redirected 
to, say, /dev/pts/1 (some graphical app) and then /dev/pts/1 disappears, 
who is going to set the tioccons back? And to what value?

That's why there is "xconsole", which does read the entire syslog and not 
just console/printk messages.



Jan Engelhardt
-- 

Re: TIOCCONS security revisited

[Olaf Dabrunz]

On 30-Jan-06, Julian Bradfield wrote:
> In August 2004, Olaf Dabrunz posted a patch, which appears to have got
> into 2.6.10, restricting TIOC_CONS to CAP_SYS_ADMIN .
> 
> He justified this by claiming that normal users don't need to grab the
> console output.

I understand that users want to see these messages and I want them to
see these messages. (I did not emphasize this but I believe I never
stated something else.)

The problem is that TIOCCONS causes security problems.

Please rehash what I wrote in the thread. Essentially, these are my
points (citing myself here):

    the ioctl TIOCCONS allows any user to redirect console output to
    another tty. This allows anyone to suppress messages to the console
    at will.

[and in a later mail:]

    Changing the ownership on /dev/console causes security problems
    (that user can usually access the current virtual terminal anytime,
    and the current one may not belong to him).

Also I refered to a security advisory for SunOS which describes one of
the problems (hijacking):

http://www.cert.org/advisories/CA-1990-12.html

And I said that there are alternatives to /dev/console, and a commonly
used one is /dev/xconsole (see below how to use this). It does not have
the security problems and has other advantages (configurable via
syslog/syslog-ng). But it also does not receive the messages that are
simply written to /dev/console.

The latter problem still needs to be fixed, but is seldom a real
problem. AFAICS nowadays only scripts that run at boot time write to
/dev/console. The user has several ways to look at these messages
already (including watching the "console" window during boot or looking
at /var/log/boot.msg).

If you want this problem fixed, consider copying messages to
/dev/console with a demon to a logging facility. Have a look at
bootlogd/blogd.

> I disagree. Normal users log into the desktop of their machine, and
> should expect to be able to see the console output just as much as if
> they logged into "the console" and worked without graphics.
> For example, I want to know when the machine I'm working on has
> problems, when somebody is probing sshd, and simply when one of my
> batch jobs wants to tell me something.

All this can be done by using /dev/xconsole.

> Further, on our systems, I own the console (ownership is transferred
> to the user by the login procedure), so it's daft that I can't call TIOCCONS
> on it.

Changing ownership of /dev/console is part of the security problem. But
you can do that with /dev/xconsole.

> I propose that a better security test would be:
> user owns /dev/console OR has CAP_SYS_ADMIN .
> 
> It should then be the responsibility of the log-out procedure to
> cancel redirections when it changes the ownership of devices back to
> root.
> 
> In December '04, Lars posted about this breakage, and proposed a
> simpler patch, allowing general TIOCCONS but restricting cancellation

Lars reported that xconsole breaks and proposed to simply revert the
kernel patch. His patch does not fix the security problems, it just
reverts to the old known-broken state.

Xconsole fails because by default it tries to use /dev/console. You can
avoid that by setting the resources to point to another file, e.g.
/dev/xconsole:

/usr/X11R6/lib/X11/app-defaults/XConsole:
XConsole.file:          /dev/xconsole

Alternatively, you can use "xconsole -file /dev/xconsole".

When my TIOCCONS kernel patch is applied, xconsole should never try to
use /dev/console. We fixed this by putting the code that checks for
/dev/console into an #if in xconsole.c:OpenConsole():

#if !defined(linux)
           if (!stat("/dev/console", &sbuf) &&
               (sbuf.st_uid == getuid()) &&
               !access("/dev/console", R_OK|W_OK))
#endif

Later on in the code we use /dev/xconsole as the default.

-- 
Olaf Dabrunz (od/odabrunz), SUSE Linux Products GmbH, Nürnberg

Re: TIOCCONS security revisited

[Julian Bradfield]

>The problem is that TIOCCONS causes security problems.
>
>Please rehash what I wrote in the thread. Essentially, these are my
>points (citing myself here):

If you insist, I will rehash them, though they are not really relevant.

>    the ioctl TIOCCONS allows any user to redirect console output to
>    another tty. This allows anyone to suppress messages to the console
>    at will.

I do not propose returning to this situation.

>[and in a later mail:]
>    Changing the ownership on /dev/console causes security problems
>    (that user can usually access the current virtual terminal anytime,
>    and the current one may not belong to him).

If this is seen as a problem, it should be fixed in the virtual
terminal system. /dev/console and TIOCCONS exist and work in many
Unices, not just Linux.

>Also I refered to a security advisory for SunOS which describes one of
>the problems (hijacking):
>http://www.cert.org/advisories/CA-1990-12.html

And how did Sun fix it? They fixed it by restricting TIOCCONS to users
who have read access to the console - more liberal than my proposal!

>And I said that there are alternatives to /dev/console, and a commonly
>used one is /dev/xconsole (see below how to use this). It does not have

I do not have the option of using /dev/xconsole.
I use machines that I don't administer, and on all of them for the
last 15 years until the recent breakage, "xterm -C" worked.

>syslog/syslog-ng). But it also does not receive the messages that are
>simply written to /dev/console.

Exactly. I have an array of programs that write to /dev/console in the
expectation that the message will be read by the person sitting at the
console.

>The latter problem still needs to be fixed, but is seldom a real
>problem. AFAICS nowadays only scripts that run at boot time write to
>/dev/console. The user has several ways to look at these messages

As I have indicated, there is a world outside your experience of
Linux. As well as my own scripts, the machines one which I work are
set up to have syslog write urgent messages to /dev/console.

>If you want this problem fixed, consider copying messages to
>/dev/console with a demon to a logging facility. Have a look at
>bootlogd/blogd.

I do not administer the machines. If you hadn't broken TIOCCONS,
everything would still work.

>All this can be done by using /dev/xconsole.

Which is not available.

>Xconsole fails because by default it tries to use /dev/console. You can
>avoid that by setting the resources to point to another file, e.g.
>/dev/xconsole:

which is not available.

Re: TIOCCONS security revisited

[Olaf Dabrunz]

On 01-Feb-06, Julian Bradfield wrote:
> >    the ioctl TIOCCONS allows any user to redirect console output to
> >    another tty. This allows anyone to suppress messages to the console
> >    at will.
> 
> I do not propose returning to this situation.

Your proposal is:

    I propose that a better security test would be:
    user owns /dev/console OR has CAP_SYS_ADMIN .

Who will own /dev/console? It can either be the root user, but then he
has that capability already. Or it can be some "special" user. But this
needs some setup by the root user then, so again root privileges are
needed.

Or you can let the login program or an X-Windows login script change the
ownership of /dev/console to the user who just logged in (as described
in the xterm manpage under option "-C").

Then a normal user who wants to hijack the console messages now logs in
to the machine and simply redirects the console. So your proposal also
"allows anyone to suppress messages to the console" and that is the same
situation that we had before. 

> >[and in a later mail:]
> >    Changing the ownership on /dev/console causes security problems
> >    (that user can usually access the current virtual terminal anytime,
> >    and the current one may not belong to him).
> 
> If this is seen as a problem, it should be fixed in the virtual
> terminal system. /dev/console and TIOCCONS exist and work in many
> Unices, not just Linux.

If you have a fix, go ahead and post it. I just remember this is
difficult. But this is just another problem with TIOCCONS on Linux that
is fixed by the patch. To replace the patch, you need a better fix for
the hijacking problem as well.

> >Also I refered to a security advisory for SunOS which describes one of
> >the problems (hijacking):
> >http://www.cert.org/advisories/CA-1990-12.html
> 
> And how did Sun fix it? They fixed it by restricting TIOCCONS to users
> who have read access to the console - more liberal than my proposal!

Sun's TIOCCONS still redirects the console output. IOW, it still hijacks
the admin's console and redirects it to the user. This is not a viable
solution for machines that routinely have their console on a serial
terminal (and are monitored through them).

One reason why Sun does this is that if they did not redirect the
console output, it would clutter up the local framebuffer and overwrite
(and even scroll) the X-Windows display. Another reason is that Sun's
machines are often not monitored over serial lines, since the default
console is on the local screen.

This is different with mid-range IBM machines, where serial lines are
routinely used to monitor the system.

> >And I said that there are alternatives to /dev/console, and a commonly
> >used one is /dev/xconsole (see below how to use this). It does not have
> 
> I do not have the option of using /dev/xconsole.

If the machines you use lack /dev/xconsole, tell the administrator or
OS vendor to fix this. You may want to mention that it is a much safer
alternative to /dev/console. ;)

> I use machines that I don't administer, and on all of them for the
> last 15 years until the recent breakage, "xterm -C" worked.

Why don't you use xconsole instead?

I do not see the reason why you have to use "xterm -C". If you really
have to, xterm should be fixed as well. Relying on the availability of
/dev/console may not work and - as the xterm manpage points out -
depends on scripts that change the ownership of /dev/console (which has
security implications in itself).

> >syslog/syslog-ng). But it also does not receive the messages that are
> >simply written to /dev/console.
> 
> Exactly. I have an array of programs that write to /dev/console in the
> expectation that the message will be read by the person sitting at the
> console.
> 
> >The latter problem still needs to be fixed, but is seldom a real
> >problem. AFAICS nowadays only scripts that run at boot time write to
> >/dev/console. The user has several ways to look at these messages
> 
> As I have indicated, there is a world outside your experience of
> Linux. As well as my own scripts, the machines one which I work are
> set up to have syslog write urgent messages to /dev/console.

Obvious solutions:
    - Change your scripts. (Why do you use /dev/console for your own
      personal "urgent" messages anyway? /dev/console is meant as a
      system monitor for the operator and the administrator, not as a
      messaging system for normal users. There are other solutions
      better suited to that (logfiles, mails, SMS, ...).)
    - Make a solution available that copies messages from /dev/console
      to some logging facility (and tell the world, because people may
      be interested in it ;) ).

> >If you want this problem fixed, consider copying messages to
> >/dev/console with a demon to a logging facility. Have a look at
> >bootlogd/blogd.
> 
> I do not administer the machines. If you hadn't broken TIOCCONS,
> everything would still work.

TIOCCONS security problems are fixed now. No better solution is
available. Safer alternatives for its functionality are available. I do
not consider this broken.

What may be broken is:

 - No /dev/xconsole: this is a problem of the administrator and/or OS
   vendor -- tell them. If you or they need pointers on how to set up
   /dev/xconsole: have a look at "man syslogd" or at a SUSE system.

 - xterm -C: use xconsole and/or fix xterm

Regards,

-- 
Olaf Dabrunz (od/odabrunz), SUSE Linux Products GmbH, Nürnberg