Future and impact of ongoing projects in Linux world

[Xen]

Colin Law schreef op 09-10-2016 9:28:
> On 8 October 2016 at 23:58, Xen <list at xenhideout.nl> wrote:
>> Colin Law schreef op 08-10-2016 18:29:
>>> 
>>> On 8 October 2016 at 17:21, Xen <list at xenhideout.nl> wrote:
>>>> 
>>>> Ralf Mardorf schreef op 06-10-2016 12:42:
>>>>> 
>>>>> 
>>>>> Just a very laste note.
>>>>> 
>>>>> On Wed, 2016-10-05 at 22:29 +0200, Xen wrote:
>>>>>> 
>>>>>> 
>>>>>> >> In Windows
>>>>>> 
>>>>>> Yes you conveniently break off my statement but (I had to look for 
>>>>>> it)
>>>>>> it was about something that has *nothing* to do with security as 
>>>>>> it
>>>>>> dealth with network shares.
>>>>> 
>>>>> 
>>>>> 
>>>>> Yes, you mentioned Windows allows to do this and that, but Linux
>>>>> doesn't, so I pointed out, that Windows is insecure and Linux 
>>>>> isn't. I
>>>>> assume causality. There are reasons that Linux does work different 
>>>>> to
>>>>> Windows.
>>>> 
>>>> 
>>>> 
>>>> And so whenever Linux can't do something, it is for security? Don't 
>>>> make
>>>> me
>>>> laugh.
>>> 
>>> 
>>> I think there is a difference between *can't* meaning is not able to
>>> and *won't allow* meaning there is something specifically stopping
>>> that from happening.  The *won't allow* features are generally for
>>> security reasons.
>> 
>> 
>> A root user also cannot do the things just mentioned.
>> 
>> The required software does not exist, for the most part.
>> 
>> There are also no security considerations whatsoever pertaining to the 
>> local
>> system regarding the mounting of remote network shares on a user 
>> supplied
>> home directory or equivalent. It is utter bull. You can make such
>> generalized statements all you want but I hear nothing that actually
>> addresses the topic.
> 
> I was not commenting on any particular topic, merely pointing out that
> that Ralf (I think) said there are some things that Linux "does not
> allow" and you answered this with a post referring to things that
> Linux "can't" do and the two things are not the same. I also stated
> that things that Linux will not allow are generally security related.
> 
> Is any of that untrue?

You might as well state that the sun is not green and that might also 
not be untrue. But the question is whether that is relevant or related 
or whether it is a showstopper.

These generalized statements are only meant to instill doubt in people 
as to the validity of what has just been said.

Someone says "Linux can still not do this thing" and someone else says 
"Linux is not Windows" as if that answers the thing.

If this topic at hand has *nothing* to do with security, then mentioning 
security as a reason for certain features not to exist, is not a valid 
thing to mention at all. It merely makes people believ "Oh, that's why, 
I better stop complaining, there are good reasons for this." No, there 
aren't. That was not valid.

Of course, the question between what a user is allowed to do (no gray 
area) and what an admin is allowed to do, IS a security related 
question. But consistently, current, we find that even when security is 
*not* at play, we still cannot do a certain thing. After all, something 
that is not possible quickly becomes possible when you use sudo. So why 
can't we?

The answer lies in the fact that many system settings are system-wide 
and that there is barely any infrastructure to keep settings per user. 
That is what I had wanted to mention... and the example of mounting 
personal network resources is actually something that has no reason 
whatsoever as to why it cannot be done with a setuid program in complete 
safety as the setuid program can simply check for user permissions 
before mounting. The mount program does the same: when it is in fstab, 
it is allowed, but when it is not in fstab, it is suddenly not allowed. 
That doesn't make much sense, particularly if we were to be talking 
about a mount point owned by the user, and when there are not actually 
any system resources at play internally in the system, that are at risk 
of being accessed (and perverted or destroyed). User mounting fails when 
the user does not have access (write access) to the mount point. That 
could be the same for network mounts, you know.

Dolphin et. al. already can access remote shares, they just cannot mount 
them. There is the ability to automatically mount stuff in 
/media/user/*, but this is a managed infrastructure where the user can't 
write, the user directory is actually owned by root.

It is also not a very convenient place to access, these days. With mount 
namepaces we could easily have per-user mount points. But the point was, 
before I started editing this, that the /media structure is not actually 
user-editable or user-configurable. There is no place wherever that can 
remember these things, unless it was in the file manager, but that is 
not a good place to remember anything "system wide" or even "user wide". 
We can create high level solutions to these problems but where does that 
leave the non-GUI user?

Any good solution is going to have to be a non-GUI solution in the first 
place, that can then be managed by a GUI.

And the only facility that is needed to begin with is to mount network 
shares by a user without any root rights to a directory owned or 
controlled by the user.

Why has this traditionally been a problem? Because NFS shares are 
system-controlled and they depend on the inability of a regular user to 
mount a filesystem for their security -- they leverage security issues 
to their clients. The client is responsible for the security of the 
server. Bad design.

Regardless on a Linux system the ordinary user would not be able to 
access files on the NFS server that did not coincide with its own user 
ID on the local system.

The NFS system is just another example of bad design, but it is going 
too far to discuss that here.

But it is another example of making the system the entire focus point 
and not the user. The weight of Linux lies on the system, and not on the 
user, and that is the problem. 90% of Linux weighs on the System. In 
Windows, it is maybe 50-50, mostly because of what the user can't do, 
but should be allowed (such as the intricate web of file permissions 
that is such as mess these days).

> I was not commenting on any particular topic, merely pointing out that
> that Ralf (I think) said there are some things that Linux "does not
> allow" and you answered this with a post referring to things that
> Linux "can't" do and the two things are not the same. I also stated
> that things that Linux will not allow are generally security related.
> 
> Is any of that untrue?

Linux allows mostly anything with a sudo password so that is untrue. 
Even when it allows it, it still cannot do it. Using sudo is so easy 
(and at the same time so annoying) that the full power of the super user 
is at all times available, just very inconvenient to use.

You can use sudo to wipe your /usr within a second, but you cannot mount 
a samba share in a convenient location no matter how hard you try. So it 
is not a question of "allowance" but /ability/ because "allowance" is 
EASY!.

Ralf said that my "Linux can't" are actually "Linux does not allow" so 
you are turning it completely around here; the call is to Ralf to prove 
that "can't do" is actually "doesn't allow", not to me to prove that 
"doesn't allow" is actually "can't do". Or actually, if you are going to 
berate me for linking the two, the fault is on someone else.

There is nothing Linux does not allow. Yes, present day RM will not 
allow you to "rm -rf /" without an extra option. That's about it. You 
are allowed to destroy your system all you want and it frequently 
happens. There is no safety and safeguards at all, seeing the amount of 
times you need to use sudo precisely /because/ the user is disallowed so 
many things, but guess what, they are the SAME PERSON.

The inability of the regular user to do ANYTHING *mandates* the constant 
use of sudo which defeats the ENTIRE separation you have been trying to 
create. It mandates using *weak* user passwords which renders root 
completely accessible to anyone who knows the account and has means to 
crack it. The system generally protects against elevating the user 
without a user password but a keylogger can be run without any sense of 
privilege and so your user password is obtained within seconds to 
minutes of you using the system in that sense.

The sudo password is no protection whatsoever and you might as well make 
it a token "yes".

Basically, anyone who can crack your user account will have root access 
within a very short time of you using the system. If you don't believe 
me, you can download something like PyKeyLogger, which I just did to 
prove the point.

My user password is now stored in unencrypted form on my system. Just 
like that. Requires no user interface, just starting a service in the 
background by the user itself (or its account).

So where is your great security now, you know. Where is your 
disallowance now. There is none. If you are in the sudo group, there is 
none.

So yes, "does not allow" and can't do are different things, but that was 
the point Ralf was trying to blend. Linux allows everything, but still 
can't do much (of user experience). Unless you are a server (and Linux 
was designed for servers, in that sense) you will have no *actual* 
separation between user and root. And I will tell you that on my 
servers, I also have sudo rights.

With sudo and the ability to run any keylogger the actual separation 
between user and root is /illusory/.

There *is* no separation if you are in the sudo group, it is just very 
inconvenient to have to type your password all the time. You know full 
well that a login can be scripted and so can a sudo prompt.

So:
- Linux allows everything
- Linux still cannot do some very basic user things.

And disallowing the user of keyloggers is also no solution, if you 
venture there.

The problem is the weight placed on the system user (administrator) 
while granting the actual user very few rights. This mandates the 
constant use of sudo to do anything and this causes the actual 
administrator account to become very accessible.

This is reflected in the inability of the user to make system-wide 
changes (or at least reflected on his own user) or to have a way to 
store configuration data for such changes (that would then still need to 
be effectuated using a sudo or setuid program).

There is simply no configuration infrastructure for anything and what 
SystemD can do today is a new thing. Windows has always had a "local 
system" "current user" separation in the registry, we don't. Yes, there 
are many places where you can configure stuff on a per-user account, but 
apart from running unprivileged containers I haven't seen much of it.

But I think it is pretty much a proven fact that the "security" of a 
Linux system is a farce. The system is no more secure than the main user 
account.

And the only reason you think Linux is secure is because it is not 
getting targetted by malware. Linux has at most 3% of the desktop 
market, is what they say. Meanwhile devices everywhere are getting 
hacked and the recent attack on security researcher Brian Krebs came 
mostly from IoT devices all running Linux. He was hit by an attack so 
large (620 Gbps) that his hosting provider (Akamai) couldn't cope with 
it and shut his website down ;-). Now Google has taken it over promising 
to be able to take the load ;-).

Linux is at 2.23% according to netmarketshare.com. You have 1/40 the 
share Windows has. Windows is forty times more popular!

I mean let that dawn on you, you know. You can claim you are all so 
amazing (and that I would be, if I use it, which I do of course) but the 
stark reality is that for everyone of you there are 39 other people who 
are using Windows and that is not counting the Mac even (at a mere 
7.01%) so in total for every Linux user there are almost 44 people using 
something else.