A requirement for the current user to own ttys

Key Offecka key.offecka at gmail.com
Sat Mar 11 23:54:36 UTC 2017


Hi,

> You did mention "sudo" a couple of times

Yes, I did. And maybe even more times, but I never told about extra rights
obtained by a user just because of sudoing.

> You keep talking about "first" and "second" user, in order to have these
you must switch user by some means

And I told you, in my test case I use sudo (please mind the *just*)

>> sudo here is just used to switch from echo to ghost

Once again, sudo is for switching users, access to echo's resources is a
different question.

> There's no sticky bit in the game, I assume you meant the setuid or
setgid bit.

Please excuse me, you are totally right, of course it's setuid bit in game
here. Sir, I have no explanations why I said 'stick bit'. Demon possession?

>> I said: the second user (`ghost` in this example) is authorised to act
on behalf of `echo`.
> This is an absolutely false expectation. It's not how things are working
(and I'm not talking about mc here). The second user does _not_ have access
to the first user's belongings. Try sudoing from a normal user to another
normal one, and then remove a file of the first user. You'll be denied
access.

Yes, but mc doesn't delete tty3. So the expectation is not necessarily
false. It depends on a particular case. In your example, it's false. But
there may be others when it's valid, for example I still can do the
following

sudo -u ghost bash -c 'echo hello echo >/dev/tty3'

just because ghost belongs to the tty group. So by giving the write
permission on tty3 to the tty group `echo` authorizes members of the group
to write to tty3. It may be not quite correct to say "echo authorizes to
act participants of the tty group on behave of them". Sorry for the unclear
wording.

But you were right I'd got a vague understanding of how it was supposed to
work. Thanks to explanations (I really appreciate your wasting time on me)
I think I now understand it's also up to the software to handle permissions.

> It's still unclear to me: What do you expect cons.saver to do differently?

And my suggestions are:

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
    else deny the access

> if I take it as a setuid root cons.saver should allow any user to
save/restore the contents of any vcs (that's what root can do anyways) then
it's a big fat NO for security reasons

I agree.

> Could you please be more specific? I do not understand what you're
_exactly_ asking for. E.g. "respect root privileges" is way too generic

By saying respect root permissions I mean that if root runs mc, root should
see the background contents and shouldn't press any key after executing
commands even though if root doesn't own the tty.

> Maybe the checks it's doing are imperfect, maybe they are a bit too
strict or paranoid and could be loosened up, I don't know.

So, I think the main question here: isn't mc too paranoid? 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?

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.

Off topic:

> It could be a matter of taste, but I definitely prefer the graphical
emulators' behavior here

You are right, it's a matter of taste.

> although I'm not sure if I should mention this

You shouldn't have to. The same way you could say: to fix the issue don't
use mc, use Krusader.

--
Best regards,
Konstantín

On 11 March 2017 at 16:24, Egmont Koblinger <egmont at gmail.com> wrote:

> Hi,
>
> On Sat, Mar 11, 2017 at 7:50 PM, Konstantin I. <key.offecka at gmail.com>
> wrote:
>
>> Hi,
>>
>> > Nope. Via "sudo", the first user is allowed to execute certain commands
>> on behalf of the second, not the other way around.
>>
>> I didn't say "via sudo"
>>
> You did mention "sudo" a couple of times. You keep talking about "first"
> and "second" user, in order to have these you must switch user by some
> means. sudo, su, perhaps ssh localhost -- can you think of any other means?
>
>
>> I said: the second user (`ghost` in this example) is authorised to act on
>> behalf of `echo`.
>>
> This is an absolutely false expectation. It's not how things are working
> (and I'm not talking about mc here). The second user does _not_ have access
> to the first user's belongings. Try sudoing from a normal user to another
> normal one, and then remove a file of the first user. You'll be denied
> access.
>
>
>> How it's done is irrelevant. You mentioned PAM. Ok. Let it be PAM.
>>
> In that case mc-devel is probably not the right forum to discuss it ;) I
> admit it sucks on Linux that it's hard to discuss cross-component issues
> and even much harder to come to an agreement and a followup implementation.
>
>
>> >He has no direct access to the vcsa3 device
>>
>> Or she, but anyway they have indirect access via the sticky bit. So it
>> shouldn't be a problem.
>>
> There's no sticky bit in the game, I assume you meant the setuid or setgid
> bit.
>
> I assume you utterly miss the responsibility of a setuid or setgid app.
> It's _not_ that it is granted tons of permissions via this bit and then can
> just freely go ahead and do whatever the filesystem's permissions allow
> them.
>
> Due to the setuid/setgid bit, it _becomes_ the responsibility of this
> helper to explicitly check plenty of conditions to decide whether or not to
> grant access to the desired device.
>
> It would be unacceptable if I could log in to a machine with ssh, and then
> using the setuid or setgid cons.saver binary I could mess with the consoles
> that probably root is using locally. cons.saver _must_ explicitly deny this
> from happening.
>
> Maybe the checks it's doing are imperfect, maybe they are a bit too strict
> or paranoid and could be loosened up, I don't know. (Note: I can't recall
> ever touching or even examining this code. I'm not defending the particular
> implementation, I'm defending the overall design.)
>
>
>> Please take a look at my ls -la outputs. Not only is tty3 owened by echo
>> but it's owned also by the tty group. And as you saw ghost is a pretty
>> powerful user. The user is a part of the tty group as well. But mc doesn't
>> care. It also doesn't care whether this is root or not.
>>
> It's still unclear to me: What do you expect cons.saver to do differently?
>
>
>> > implementing alternate screen support in the Linux tty driver, or using
>> a graphical emulator. I can't see how mc could solve this issue.
>>
>> That would be overkilling.
>>
> No, IMO that would not be overkilling, that would be the proper solution.
> Also, all other apps (well, their users) would benefit from this: The
> previous contents would be restored upon quitting from vim, emacs, less and
> so on.
>
> It could be a matter of taste, but I definitely prefer the graphical
> emulators' behavior here. It makes no sense to me to leave (almost) a
> screenful of these apps onscreen at an arbitrary position where I happened
> to stand when I quit, and to lose the last screenful of my bash activity
> whereas older activity is still accessible with Shift+PageUp.
>
> And on a totally irrelevant note (although I'm not sure if I should
> mention this, I absolutely don't want to initiate a flame war): I
> personally don't see any reason to use the Linux console over graphical
> terminal emulators, except for rare critical events. As such, convenience
> like Ctrl+O after a sudo is absolutely unimportant for me. Systems that
> don't have graphical environment (that is, servers) should be accessed
> remotely. Graphical terminal emulators support more features than the Linux
> console, have a magnitudes larger scrollback that you don't lose when you
> switch to a different one, can search in the scrollback, look so much
> nicer, are more configurable, can be arranged freely using your favorite
> desktop environment, you can see more of them at the same time, you don't
> have to type your password every time you with to have a new one, let alone
> you can have other essential apps (e.g. browsers) visible and even
> copy-paste between them and so on and so forth. (I used to be a heavy Linux
> console user, even "startx"-ing only for those short times when I needed a
> graphical app, geez, that was so last century...)
>
> Why not just to follow standard *nix conventions? To respect root
>> privileges at least. May I dare to ask to respect group permissions as well
>> ;-)
>>
> Could you please be more specific? I do not understand what you're
> _exactly_ asking for. E.g. "respect root privileges" is way too generic,
> and if I take it as a setuid root cons.saver should allow any user to
> save/restore the contents of any vcs (that's what root can do anyways) then
> it's a big fat NO for security reasons. I hope this is clear to you by now.
> The setuid/setgid bit grants much more to cons.saver that it needs to have,
> and so it has to deliberately cut back on its own privileges.
>
>
> cheers,
> egmont
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midnight-commander.org/pipermail/mc-devel/attachments/20170311/c680096b/attachment.html>


More information about the mc-devel mailing list