Colin Law schreef op 09-10-2016 9:28:
On 8 October 2016 at 23:58, Xen <l...@xenhideout.nl> wrote:
Colin Law schreef op 08-10-2016 18:29:
On 8 October 2016 at 17:21, Xen <l...@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.
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
