<similar ping-pong attributions snipped>
Sorry about the bulky quotage for context...
Of course. A long directory listing shows the permissions next to each file.
And a "short" listing shows what? Bearing in mind that often the user
will be presented with files to "open" outside the CLI context - so
info should be embedded within every UI representation of the file.
The owner of the file can read and write to the file.
The file cannot be "executed" or "run".
The owner can read and write and execute the file.
I don't think that answers the Q at all. Consider this state chart:
File type vs. permissions: Exec NoExec
Data file A B
Code file C D
In the above, only case C should run as code, but if I see masses of
case A all the time, I may ASSume a file is harmlessly marked as
"executable permissions" if I am expecting it to be a data file,
unless I can see (through the UI) that it is in fact a code file.
UI'ing permissions alone (and preferably less cryptically than
"-rwxrwxr-x") is only "enough" if case A never exists.
Data and code are different beasts. A data file cannot be executed, even if
one was going to set its permission as executable.
That has been contested. It's true that all content is interpreted
("run") by something, whether it be...
- the user's brain (e.g. phishing textual SE)
- a data interpreter, e.g. Notepad
- a richer data interpreter, e.g. Wordpad
- a runtime script interpreter, e.g. MS Word, WSH, etc.
- a compile-time source interpreter
- a code emulator, e.g. to run ZX Spectrum games on a PC
- hardware CPU interpretation as native code
- other hardware interpreters
....but IMO a distinction should be maintained in the interests of
"safe hex", and vigorously enforced by a sensible OS. Because the
line can be crossed through exploits of code defect (so that e.g. a
by-design "data" type like .JPG can become a raw code menace thanks to
a defect in GDIPlus.dll), one also needs tight type discipline.
We are familiar with that in the context of programming and
strongly-typed variables. Because disasterously insane results can
follow a type error, strongly-typed programming languages will refuse
to compile unless all type references are unambiguous and all variable
names are pre-defined as being of a particular type.
We need the same discipline with file types. A file that is
internally one type, but is visibly UI'd as if it were another, should
NOT be handled as an "honest mistake" that should be glossed over by
the OS by helpfully handling as the internal (hidden) type.
The two run in different parts of memory. A buffer overflow in the user
space cannot impact that part of memory that the kernel runs in.
I've been hearing those sort of assurances since Win3.yuk; it's always
"...and because each process resides in its own memory allocation, an
application crash can't bring down the whole PC !" with every new
release on Windows then, and ever since. And yet I regularly see
pure-software hard lockups of every version of Windows, plus every
Linux I have tried (e.g. BitDefender Live CDR)
It helps if the processor is in a position to enforce this at the
hardware level, either via the new NoeXecute feature, or rings of
protection levels and exception handling, or separation of data from
code segments (going backwards, historically).
I suspect OOP has undermined the last, by mixing code and data on a
per-object basis in contrast to the DOS-era practice of storing data
and code in separate memory segments.
Not so with *NIX as every process is controlled by an appropriate user. So
for example, say you are running a web server on *NIX. The user "apache"
becomes the user on the system that responds to requests and sends them out
to a client. The user "apache" has no rights to overwrite files in the /etc
directory where pretty much most of the system's configurations files lay.
No matter what scripts might be thrown at the web browser, they can't
impact these config files because they are running as a user without
permission to write or execute files outside of it's designated directories
that it owns. Windoze on the other hand doesn't have this kind of security.
Well, let's take a typical (Windows) example, and you can tell me how
*NIX would improve matters. A limited-rights user logs in and has
access only to that user's data files, nothing else. The user runs a
"bad" program, which then uses the user's rights to trash the user's
data. No problem for IT vendor support as there's no "damage" for
which they are responsible (i.e. they don't have to intervene to get
Windows running again) but irreplaceable data is lost.
That's why I do not see "user rights" as the answer - no matter how
limited these rights, and bad code that gets to run with those rights
can do material damage. The only answer is to make it less likely
that bad code will get to run, by ensuring that:
- system doesn't run code ahead of the user's intent
- user can assess the risk level of content before running it
Scripkiddies can send a request the web server and that web server can get
into areas of the system and do damage. Happens all the time.
That's often the difference between intended and actual behaviour. As
I understand it, *NIX hard-links this to an actual path heirarchy,
whereas the NT security model binds these permissions onto content
across directory tree - the latter being more flexible, but harder to
really know what is likely to happen just by looking at paths.
If either mechanism is set up "properly", chances are both will work
unless there are code defects that allow the attacker to drill right
through the whole sandcastle. But, etc.
The same thing applies if you are a user. You have rights to your home
directory. But you can't go into the /etc directory and delete or alter
files there. So even if your space gets a virus, that virus can only do
damage within your space
Thanks, but I don't want viruses to do damage "only" within my space.
I'm sure Lufthansa would be very happy if an attacker shot me on one
of their airplanes, and no damage was incurred outside the confines of
my body, thus protecting their resources.
It doesn't work for me, tho. Next!
*NIX was designed from the ground up as a server/client operating system and
a multiuser operating system. Windoze is not.
As I recall, communication was always a strong focus with *NIX, as was
multitasking and multiple users. As you say, "Windows" wasn't, but
OTOH NT did concern itself with "security" from early in its life, if
not from the very outset.
The problem is that "security" is no substitute for "safety" - in
fact, consumers may have been better off with unsecured Win9x when it
comes to safety, because a standalone OS doesn't have wads of
edge-facing network surfaces waved at the 'net.
Hence zero Lovesan/Blaster exposure, zero Sasser exposure, etc.
Windoze by default sets up new users as having admin rights when first
installed. This is crazy, and contributes to the major insecurity of a
Windoze box.
Not as much as you'd expect, for reasons mentioned above (lowered
rights do zero to protect user data, because all users have the right
to edit their own data). If Windows changed that tomorrow, so that
all new accounts were limited rights (leaving just the one built-in
admin account that always has the same predictable name, hmm), the
users would have to escalate those rights to run the majority of
today's games and apps. The OS *exists* to run those, remember...
An admin with windows has to specifically go out of his/her
way to secure the box and try and keep ordinary users away
from sensitive o/s files. Even then, a virus can do extreme
damage to the point of breaking the o/s.
Well, the focus would be in the wrong place for the consumer market,
where we do NOT consider the user to be "the enemy". The idea is to
empower the user to have full control, and keep anything that is not
run by choice of the user from doing anything whatsoever.
Can't happen on a Linux system.
Assertion != proof... yes, you can tell me what the design intention
is, but I'd have to remain sceptical that the reality is effectively
confined by that intention.
That's just so much Microsoft FUD. Windoze is targeted because of its
inherent insecurity, not because of market share.
Another assertion that I don't think is provable. Even if someone
identified and canvassed the top 10 000 malware vendors, would you
believe the answers you got back?
Not only is Linux a smaller target than, say, Windows XP, Windows 98,
Acrobat Reader for Windows, WinZip for Windows, etc. its market share
is further fragmented by all the different dialects (distros).
A great target would be any server connected to the Internet - web server,
mail server, etc. The majority of the Internet is now driven on Linux/*NIX
servers. The targets are clearly there and the ports are open. Think about
why the Internet isn't being successfully attacked constantly.
It's not necessary to attack servers directly, when consumers have
graduated from slow and sporadic dial-up to always-on broadband.
Servers are likely to be better secured, regardless of OS, simply
because they will usually be professionally staffed.
Instead, attacks are made on consumer boxen, either as the primary
target (e.g. phishing for credit card numbers) or to recruit them as
zombie cats-paws to hammer servers (e.g. DDoS attacks).
"Haven't you heard?? Don't-cha watch-a TV??" [Buckaroo Banzai]
---------- ----- ---- --- -- - - - -
Don't pay malware vendors - boycott Sony
