Re: Strong Security Aspects of Unix OS:
From: Juha Laiho (Juha.Laiho@iki.fi)Date: 01/30/02
- Previous message: Fabian La Maestra: "Strong Security Aspects of Unix OS:"
- In reply to: Fabian La Maestra: "Strong Security Aspects of Unix OS:"
- Next in thread: Casey Schaufler: "Re: Strong Security Aspects of Unix OS:"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Juha Laiho <Juha.Laiho@iki.fi> Date: Wed, 30 Jan 2002 20:46:34 GMT
flamaest@yahoo.com (Fabian La Maestra) said:
>Have you had any success? I am also looking to dig into these issues..
>May I read your paper?
>Hi ...i'am doing a report on the strong and weak aspects of the Unix
>OS, i surfed the Internet and i found tons of information regarding
>the Unix weakness like finger,rusers etc ......but relatively few
>information could be retrived concerning its strong points.
Homework?
>Well the most famous fact abt Unix is that it doesn't crash like
>Windows does ..but other that its robustness against process
>failure..is there anything else which can be highlighted ??
The root causes for process failures might well be security risks
as well.
> I was thinking of the password mangement performed by Unixs, they
>accept a users password, encrpyt it with that particulars user's SALT
>and then compare it with a shadow password file(correct me if i am
>wrong on this procedure).
This is one way (and the most common); there are others (look up
Kerberos authentication for a different one).
> Another strong aspect i thought of is the file permission, a owner
>is able to set for its files and directories ?
Actually I'd like to get VMS (WinNT...) like permission system on
Unixes; the traditional user/group/world isn't always sufficient.
But on with your topic; I'd say security comes with a clear distinction
between "authorized" and "not authorized", and between "inside" and
"outside". Once these are conceptually defined, then the concepts need
to be turned into correct programs. Simplicity is a key issue for
program correctness: both the concept has to be as simple as possible,
and the implementation of the concept must be done in a way as simple
as possible. (probability of logic and/or programming errors in a
program rises with growing program sizes, and additionally small
programs are easier to verify for correctness than large ones)
One clear inside/outside distinction on Unix is that direct access to
hardware devices is only allowed for the operating system kernel itself.
Any user access must be done via the virtualised devices provided by
the operating system.
F.ex. there are things like "/dev/dsk/...", which represent the actual
disk drives installed on the system. When some program wishes to access
the disks directly, it will open one of these so-called device entries
and process it like a huge file. The permissions for users to access
this are set using the regular Unix filesystem permissions of owner,
group and others. Typically the owner for these device files is root,
and only owner is given any kind of permission to access the disks
directly. Similar abstractions can be found for many other devices.
One thing that is often needed is some way to give a trusted program
more privileges than the user executing the program normally has.
How this is done on Unix systems will be my example of simplicity.
To the example: passwords are stored in a regular text file
(traditionally in /etc/passwd, presently often in /etc/shadow). To
change his/her own password, the user must be able to change (edit) the
file. But if a general editing (write) permission was granted to the
file, anyone with access to the system could change any password. The
solution has been to write a small program that checks the identity of
the invoking user and does limited editing of this password file (only
changes the password of the invoking user). Then, there is a special
permission bit on top of the regular user/group/world read/write/execute
sets that will, when the program is run, check who is the owner of
the program executable file, and set the privileges of the program to
the owner of the file instead of the user who actually is running the
program. So, the executable for the program to change the passwords is
made owned by "root" and is marked to have the privileges of the owner
(i.e. root) when the program is run. As root is implicitly allowed to
modify any file on the system, then any user running this authorized
password changing program will be able to modify the password file.
Additionally, the authorization is conneted to a file instance; if
someone copied the password changing program, the copy would not
have the extra privileges any more.
This brings us to another simplicity in Unix. There are two different
permission levels; "root" and "all others". No account besides root
has any special powers. All other accounts are authorized based on the
user id or group memberships of the accessing accounts and ownerships
and permissions of the accessed objects.
So, there are numerous simple principles that have been set mostly at
the very early phases of the Unix operating system design. The initial
implementations of these were largely correct, and there has been 30
years time to find out and fix the mistakes. As Unix source code has
been available for purchase at a (more or less) reasonable price, it has
been widely studied and enhanced - and much of the enhancements have
been fed back to the original code, thus sharing them with other users
and strengthening the overall code base.
I think one important factor for the quality of the old Unix code has
been the roughness of the programs: while little effort was spent to
make them look "nice", most of the programming effort was targeted
to make the programs function correctly. Also, as computing power was
a scarce resource, a cute user interface would've been considered
wasting the valuable resources. An important driver for the
application correctness was also that many of the core utilities were
programmed to be tools to use in larger programs. While humans tolerate
variation in program functionality rather well, when interfacing multiple
programs with each other, variation in the functionality causes endless
grief.
I hope this was of any help. Sorry that it's rather unstructured; my
thoughts are not flowing as clearly as they could.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)
- Previous message: Fabian La Maestra: "Strong Security Aspects of Unix OS:"
- In reply to: Fabian La Maestra: "Strong Security Aspects of Unix OS:"
- Next in thread: Casey Schaufler: "Re: Strong Security Aspects of Unix OS:"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
