Re: A requirement for the current user to own ttys

[Egmont Koblinger]

Hi,

cons.saver, as you apparently know this, is the helper binary responsible
for restoring the contents of the Linux console when you quit mc or press
Ctrl+O. A helper is required since the Linux console does not have an
"alternate screen" that graphical terminal emulators have.

In order to be able to do this, it needs read/write access to /dev/vcsa*.

When you log in on the console, the corresponding /dev/tty* becomes owned
by you but /dev/vcsa* don't. I believe the reason behind it is that there
is a way to revoke the tty from you, but there is no way to revoke the vcsa
access. That is, when you log out, you might keep a background process
running which still has access to it via a previously opened file
descriptor, and subsequently as someone else logs in, you could spy on the
console's contents.

As such, since /dev/vcsa* is not owned by the desired user, cons.saver
needs to be setgid tty (or setuid root).

Setuid/setgid apps must have all these kinds of precautions that you're
asking about, they need to duplicate the permission checks because they are
not being run as the actual real user. It's crucial that someone not
actually sitting in front of the tty cannot trick cons.saver into tampering
with the tty's contents.

Hope this explains the situation.

I'm not sure why something is checked twice, but it can easily be in order
to avoid a race condition (or could easily be a harmless bug as well).

egmont


On Fri, Mar 10, 2017 at 1:06 AM, Key Offecka  wrote:

> Hi,
>
> I am looking at the
>
> main (int argc, char **argv)
>
> function in
>
> src/consaver/cons.saver.c
>
> There are calls like
>
> st.st_uid != uid
>
> fstat (console_fd, ) >= 0 && st.st_uid == uid
>
> fstat (console_fd, ) < 0 || st.st_uid != uid
>
> The last one is especially strange taking into account that it appears
> twice
>
> if (seteuid (euid) < 0
> || lseek (vcsa_fd, 0, 0) != 0
> || fstat (console_fd, ) < 0 || st.st_uid != uid
> || read (vcsa_fd, buffer, buffer_size) != buffer_size
> || fstat (console_fd, ) < 0 || st.st_uid != uid)
>
> This all is taken from the commit e9fd11bfcd1dab97e3ba423bcfb8b6ca1088b11c
> which is the latest at this moment
>
> It looks to me MC tries inventing its own permission scheme rather than
> relying on the system set up.
> Consider there is a user in the system who is allowed to read/write and to
> do whatever they want with vcs, tty and with whatever files else you may
> only wish. root is one obvious candidate but nothing restricts us to set up
> another user taking advantaged of  all those system security facilities.
> There is a traditional UNIX permission scheme, SeLinux may be involved if
> needed. And now comes MC, and introduces a hardcoded/unconfigurable/solid
> as a stone requirement for the current user to be the owner of the files.
> Why so?
>
> I believe there is case and that code is called to cover it. But
> unfortunately I do not see the reason. And this is my question, I would
> appreciate if anybody could explain what security issue was addressed here?
> In my particular case this code introduces an inconvenience, so I just
> removed it and feel total happy without it. But still am a little bit
> concerned about possible consequences which I do now understand at the
> moment.
>
> My case I mentioned above is as follows:
>
> Log into, say, tty3 as a normal user, say `echo`. The tty3 ownership
> changes, and the `echo` user becomes the owner of tty3 which sounds
> reasonable.
> Now sudo as another user who has all access permissions to tty and vcs, In
> my case this is root.
> Press Control+O, MC screws up the background shell, the root user sees the
> blank screen rather than previously executed commands and MC starts
> thinking the terminal is dumb asking to press any key after executing
> commands. And this happens for the root user! MC overwrote the root
> privileges! Does it sound reasonable to you?
>
> Any explanations are welcome.
> Thank you.
>
> --
> Konstantin I.,
>
>
> ___
> mc-devel mailing list
> https://mail.gnome.org/mailman/listinfo/mc-devel
>
>
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

A requirement for the current user to own ttys

[Key Offecka]

Hi,

I am looking at the

main (int argc, char **argv)

function in

src/consaver/cons.saver.c

There are calls like

st.st_uid != uid

fstat (console_fd, ) >= 0 && st.st_uid == uid

fstat (console_fd, ) < 0 || st.st_uid != uid

The last one is especially strange taking into account that it appears twice

if (seteuid (euid) < 0
|| lseek (vcsa_fd, 0, 0) != 0
|| fstat (console_fd, ) < 0 || st.st_uid != uid
|| read (vcsa_fd, buffer, buffer_size) != buffer_size
|| fstat (console_fd, ) < 0 || st.st_uid != uid)

This all is taken from the commit e9fd11bfcd1dab97e3ba423bcfb8b6ca1088b11c
which is the latest at this moment

It looks to me MC tries inventing its own permission scheme rather than
relying on the system set up.
Consider there is a user in the system who is allowed to read/write and to
do whatever they want with vcs, tty and with whatever files else you may
only wish. root is one obvious candidate but nothing restricts us to set up
another user taking advantaged of  all those system security facilities.
There is a traditional UNIX permission scheme, SeLinux may be involved if
needed. And now comes MC, and introduces a hardcoded/unconfigurable/solid
as a stone requirement for the current user to be the owner of the files.
Why so?

I believe there is case and that code is called to cover it. But
unfortunately I do not see the reason. And this is my question, I would
appreciate if anybody could explain what security issue was addressed here?
In my particular case this code introduces an inconvenience, so I just
removed it and feel total happy without it. But still am a little bit
concerned about possible consequences which I do now understand at the
moment.

My case I mentioned above is as follows:

Log into, say, tty3 as a normal user, say `echo`. The tty3 ownership
changes, and the `echo` user becomes the owner of tty3 which sounds
reasonable.
Now sudo as another user who has all access permissions to tty and vcs, In
my case this is root.
Press Control+O, MC screws up the background shell, the root user sees the
blank screen rather than previously executed commands and MC starts
thinking the terminal is dumb asking to press any key after executing
commands. And this happens for the root user! MC overwrote the root
privileges! Does it sound reasonable to you?

Any explanations are welcome.
Thank you.

--
Konstantin I.,
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel