Re: A requirement for the current user to own ttys

[Egmont Koblinger]

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 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
___
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,

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

> Hi,
>
> On Sat, Mar 11, 2017 at 7:50 PM, Konstantin I. 
> 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 

Re: A requirement for the current user to own ttys

[Egmont Koblinger]

Hi,

On Sat, Mar 11, 2017 at 7:50 PM, Konstantin I. 
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 

Re: A requirement for the current user to own ttys

[Konstantin I.]

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"

I said: the second user (`ghost` in this example) is authorised to act on 
behalf of `echo`.


How it's done is irrelevant. You mentioned PAM. Ok. Let it be PAM. Not sure 
how to set it up, but that's not important. sudo here is just used to 
switch from echo to ghost. How ghost then gains the access to echo's 
resources is a different question.



Seems your 'ghost' is a pretty power user.


That doesn't matter. That could've been root. root is rejected to see the 
background as well. It doesn't sound sane to me.



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.


and the corresponding tty3 is owned by 'echo'. How do you think mc's 
cons.saver should figure out that it's safe to grant access?


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.


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


--
With all my respect,
Konstantín





Sent with AquaMail for Android
http://www.aqua-mail.com


On 11 March 2017 12:41:00 pm Egmont Koblinger  wrote:


Hi,

The requirement here is that the second user (`ghost` in this example) is

authorised to act on behalf of `echo`.



Nope. Via "sudo", the first user is allowed to execute certain commands on
behalf of the second, not the other way around. During this, the second
user doesn't have any access to the first user's resources (e.g. files
under its home). As such, it's utterly irrelevant whether tty3 is owned by
'echo' (the first user) or not. It's not owned by 'ghost' (the second
user), so no access.

If you wish to grant access to tty3 for 'ghost', this should be done by
sudo or the pam framework or whatever, definitely not mc.



echo:/etc/init.d$ groups ghost
ghost : users root tty wheel



Seems your 'ghost' is a pretty power user. E.g. he can write to the tty
devices, or even hijack the data that's being typed there. Definitely not
something a regular user should have. Plus the root and wheel groups. As
such, you might just as well put the vcsa devices in a group and chmod 660
and hence allow the ghost user to directly access them.



Question: does mc work in this case as it was designed?



It's a compromise due to the lack of alternate screen support. I'd say mc
was designed to paint on the alternate screen, but due to lack thereof it
needed to find a workaround.

behaviour I would expect: in the example above mc shouldn't stop after

executing commands and should show previous command output.



mc is being executed as user 'ghost'. He has no direct access to the vcsa3
device, and the corresponding tty3 is owned by 'echo'. How do you think
mc's cons.saver should figure out that it's safe to grant access?



I think to achieve the goals you mentioned above (to not allow others to
see what they shouldn't see) another solution should be found. Do you agree?



Yup, like implementing alternate screen support in the Linux tty driver, or
using a graphical emulator. I can't see how mc could solve this issue. If
you can, let us know.


cheers,
egmont
___
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,

The requirement here is that the second user (`ghost` in this example) is
> authorised to act on behalf of `echo`.
>

Nope. Via "sudo", the first user is allowed to execute certain commands on
behalf of the second, not the other way around. During this, the second
user doesn't have any access to the first user's resources (e.g. files
under its home). As such, it's utterly irrelevant whether tty3 is owned by
'echo' (the first user) or not. It's not owned by 'ghost' (the second
user), so no access.

If you wish to grant access to tty3 for 'ghost', this should be done by
sudo or the pam framework or whatever, definitely not mc.


> echo:/etc/init.d$ groups ghost
> ghost : users root tty wheel
>

Seems your 'ghost' is a pretty power user. E.g. he can write to the tty
devices, or even hijack the data that's being typed there. Definitely not
something a regular user should have. Plus the root and wheel groups. As
such, you might just as well put the vcsa devices in a group and chmod 660
and hence allow the ghost user to directly access them.


> Question: does mc work in this case as it was designed?
>

It's a compromise due to the lack of alternate screen support. I'd say mc
was designed to paint on the alternate screen, but due to lack thereof it
needed to find a workaround.

behaviour I would expect: in the example above mc shouldn't stop after
> executing commands and should show previous command output.
>

mc is being executed as user 'ghost'. He has no direct access to the vcsa3
device, and the corresponding tty3 is owned by 'echo'. How do you think
mc's cons.saver should figure out that it's safe to grant access?


> I think to achieve the goals you mentioned above (to not allow others to
> see what they shouldn't see) another solution should be found. Do you agree?
>

Yup, like implementing alternate screen support in the Linux tty driver, or
using a graphical emulator. I can't see how mc could solve this issue. If
you can, let us know.


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 Egmont,

> What do you mean the tty owner is the _problem_? What kind of problem?

Please excuse me, I wasn't quite correct there.

Let's forget about permissions and TTYs. Let's look at the issue from the
user point of view. Please consider this case:

There is a user, say `echo` and there is another user, say `ghost`. It can
also be `root` but that is not necessary. The requirement here is that the
second user (`ghost` in this example) is authorised to act on behalf of
`echo`. User `echo` logs on a tty, say tty3. In terms of permissions (OK,
it's difficult to forget about them), ghost is a part of the tty group

echo:/etc/init.d$ ls -la /dev/tty3
crw-rw 1 echo tty 4, 3 mar 11 09:40 /dev/tty3

echo:/etc/init.d$ groups ghost
ghost : users root tty wheel

echo:/usr/lib/mc$ ls -la cons.saver
-rwsr-sr-x 1 vcsa root 10144 mar 11 09:49 cons.saver

echo:/usr/lib/mc$ ls -la /dev/vcs{,{,a}3}
crw--- 1 vcsa root 7,   0 mar 11 09:28 /dev/vcs
crw--- 1 vcsa root 7,   3 mar 11 09:28 /dev/vcs3
crw--- 1 vcsa root 7, 131 mar 11 09:28 /dev/vcsa3

The logged in user `echo` does sudo like so

sudo -u ghost mc

Now we execute a command in mc, mc runs it but before returning back it
shows that ugly message about any key. If we press something, we return to
the normal mc panels, but if we want to see the printed results of the
previously executed command, we see the blank screen.

Question: does mc work in this case as it was designed?
The behaviour I would expect: in the example above mc shouldn't stop after
executing commands and should show previous command output.

The same issue is valid for root, root is just more obvious example of the
misbehaviour.

And the reason of the misbehaviour in my opinion is that there is a
requirement for the tty to be owned by `ghost` in this example. And as I
mentioned several times before, this comes from this sort of comparison

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

That piece of information shouldn't be used like so. I think to achieve the
goals you mentioned above (to not allow others to see what they shouldn't
see) another solution should be found. Do you agree?

--
Konstantin


On 11 March 2017 at 04:37, Egmont Koblinger  wrote:

> Hi,
>
> > All you say about vcs* sounds reasonable, unfortunately according to the
> code, the tty owner is the problem.
>
> What do you mean the tty owner is the _problem_? What kind of problem?
>
> I believe it's not the _problem_, it's the piece of information we rely on
> to figure out if cons.saver is being run as a legitime user.
>
> > Disregarding of what was the intention,  disregarding of what you were
> trying to achieve and what security hole to close, do you think, that sort
> of comparison is valid here?
>
> I'm not aware of the details of the code and don't have time to dig into
> it, sorry.
>
> As far as I understand, your problem is: You expect that if the real user
> is root, cons.saver should dutifully perform its role rather than bail out
> due to some ownership mismatch. Am I right? If so, I believe it's a fair
> request, although possible security implications should be double checked.
> Could you please file a new bug for this?
>
> Thanks,
> egmont
>
>
___
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,

> All you say about vcs* sounds reasonable, unfortunately according to the
code, the tty owner is the problem.

What do you mean the tty owner is the _problem_? What kind of problem?

I believe it's not the _problem_, it's the piece of information we rely on
to figure out if cons.saver is being run as a legitime user.

> Disregarding of what was the intention,  disregarding of what you were
trying to achieve and what security hole to close, do you think, that sort
of comparison is valid here?

I'm not aware of the details of the code and don't have time to dig into
it, sorry.

As far as I understand, your problem is: You expect that if the real user
is root, cons.saver should dutifully perform its role rather than bail out
due to some ownership mismatch. Am I right? If so, I believe it's a fair
request, although possible security implications should be double checked.
Could you please file a new bug for this?

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