Re: A requirement for the current user to own ttys

[Egmont Koblinger]

On Sun, Mar 12, 2017 at 10:08 PM, Egmont Koblinger  wrote:

> So, again, if I'm not mistaken, cons.saver basically does the following:
> Based on the ownership, permissions etc. of _/dev/ttyX_, it either grants
> or denies access to _/dev/vcsaX_. You cannot examine the ttyX and the vcsaX
> story independently from each other. They are both part of 1 single complex
> story.
>

Note: I've not checked the source. This is what I firmly believe cons.saver
does, but I might be mistaken. Please correct me if I'm wrong.

e.
___
mc-devel mailing list
https://mail.gnome.org/mailman/listinfo/mc-devel

Re: A requirement for the current user to own ttys

[Egmont Koblinger]

Hi,

Why do you think on my system I cannot access vcs* devices. As far as I
> remember I never said that.
>

You did include the output of "ls -l /dev/vcs*" on your system, showing
that they're owned by vcsa and chmod 600. So, they are not directly
accessible to your 'echo' or 'ghost' users. They might be accessible via
cons.saver.


> 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.
>

So, again, if I'm not mistaken, cons.saver basically does the following:
Based on the ownership, permissions etc. of _/dev/ttyX_, it either grants
or denies access to _/dev/vcsaX_. You cannot examine the ttyX and the vcsaX
story independently from each other. They are both part of 1 single complex
story.


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

Re: A requirement for the current user to own ttys

[Key Offecka]

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, ) < 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  wrote:

> Hi,
>
> On Sun, Mar 12, 2017 at 12:54 AM, Key Offecka 
> 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
>>