Re: A requirement for the current user to own ttys

[Key Offecka <key offecka gmail com>]

Hi,

> What do you mean by "the resource" in the lines above? There are at least two pieces of resource in the game, the tty and the vcsa (maybe more, I don't know). We'd need a much more precise description.

>> if a user doesn't own the tty device but is a member of a group owning the tty should that user have the dumb terminal?

I was talking only about tty devices here. I didn't mention vcs* in any manner.

> On your system where these vcsa devices cannot normally be accessed by a member of the tty group _and_ the real user is not the same as the tty's owner, I'm not convinced yet why permission should be granted.

Why do you think on my system I cannot access vcs* devices. As far as I remember I never said that. I am sorry if didn't make it clear. On my system cons.saver is owned by the vcsa user and has the setuid bit. vcs* devices are owned by the vcsa user as well, and the user has read/write permissions.

Once again, my questions were only about tty devices. I do not know why you're answering questions I never asked.

I am not sure if the same security policy should be applied to vcs* devices. All my questions were only about tty since the access to tty devices causes the issue. There are no problems with vcs* on my system, though some improvements of mc may also be needed here.

At this moment, as far as I can read the C code, vcs* and tty* devices treated differently. There are no special checks on vcs* done at all. So I believe access to the vcs* is relied only on the OS security. There are special checks on tty and from my perspective they are too paranoid since involve only the user owning devices. 

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

|| read (vcsa_fd, buffer, buffer_size) != buffer_size

console_fd is a tty device here not vcsa

As I mentioned, I think groups also should be involved in the checks of tty devices. That's it. Nothing more.

Anyway, thank you very much for the discussion. I believe the both sides received all needed information. It's now up to you whether you want to change something in the mc security or not, whether you want to make it less paranoid or not.

--

Best regards,

Konstantín

On 11 March 2017 at 19:57, Egmont Koblinger <egmont gmail com> wrote:

Hi,

On Sun, Mar 12, 2017 at 12:54 AM, Key Offecka <key offecka gmail com> wrote:

if the user (the real user, not the effective one) is root then permission check is successful

else

  if the user owns the resource then permission check is successful

  else 

    if the user belongs to the group owning the resource then permission check is successful

I guess we should also add "and the resource is read-writable by its group"

 

    else deny the access

What do you mean by "the resource" in the lines above? There are at least two pieces of resource in the game, the tty and the vcsa (maybe more, I don't know). We'd need a much more precise description.

So, I think the main question here: isn't mc too paranoid?

It could easily be, dunno.
 

To answer this question we could try answering some more specific questions:

How do you think

1) is it OK that in the descried example root has that dumb terminal? 

2) if a user doesn't own the tty device but is a member of a group owning the tty, should that user have the dumb terminal?

There are two sides of the story: the user-expected behavior and the technical possibilities. Not sure if the two match here. Normally I'd always put the user-facing behavior first and do the technical bits to implement the expected user-facing behavior. Having a setuid/setgid bit changes the game quite a bit, compromises might become necessary, not having a security hole becomes the number one priority even if the user-facing behavior suffers from drawbacks.

What I would say is: If the actual real user has the sufficient access to the tty and vcsa devices even without a setuid/setgid bit (in other words: they could compile and install a modified version of cons.saver for themselves which removes all the current verifications and just tries to operate on the devices and would succeed even without the setuid/setgid bits) then the checks we have in place should not introduce any obstacles. There's no point in denying something that a non-setuid/setgid appication could do.

This definitely covers your 1st point. Root should always have access.

I am not convinced about the 2nd. On my system (Ubuntu) the vcsa devices belong to the tty group and have read-write perms for this group, so on my system, yes. On your system where these vcsa devices cannot normally be accessed by a member of the tty group _and_ the real user is not the same as the tty's owner, I'm not convinced yet why permission should be granted.

Note that there's also the capabilities subsystem which I know nothing about.

On the both questions personally I answer: no and no. It's not OK that root has the dump terminal, in my opinion it's not OK for a member of the tty group to have the dumb terminal.

This is a heavily security sensitive topic. Any change should be backed up by something stronger than an "in my opinion", any loosening should be thoroughly reviewed, and if there's any doubt, we should err on the side of being paranoid and restrictive rather than risking a security/privacy/dataleakage hole.

I'm not against improving the situation at all, but I'd like to see a strong justification behind every requested change, examining why that change cannot be used maliciously much rather than why it solves something on your setup.

cheers,

egmont