A requirement for the current user to own ttys
Key Offecka
key.offecka at gmail.com
Sun Mar 12 18:39:20 UTC 2017
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 at gmail.com> wrote:
> Hi,
>
> On Sun, Mar 12, 2017 at 12:54 AM, Key Offecka <key.offecka at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midnight-commander.org/pipermail/mc-devel/attachments/20170312/edbb83e7/attachment.html>
More information about the mc-devel
mailing list