lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
From: dfs at roaringpenguin.com (David F. Skoll)
Subject: Counseling not to use Windows (was Re: Anonymous
 surfing my ass\!)

On Mon, 15 Jul 2002, Roland Postle wrote:

> Agreed complexity is the enemy of security, but unix file permissions are
> nothing but an unfortunate relic of the past.

Not arguing with that.  UGO are simple, but not very flexible.  They
can be made to work well in most situations, though, especially if you
use the modern setup whereby each user has his own group, and then you make
additional groups for projects.

> Then we come to the suid/sgid bits. What are they really about? It took me
> over a year of using unix to figure it out. If this file is executed it runs
> in the security context of it's owner and/or group. Is that a permission?

Nope.  It's a "file mode".

> The idea is to create 'program domains'
> (what a program can do or can't do, as opposed to what a user can do or
> can't do), but the fact that they're implemented as user domains is another
> fudge. And an extremely confusing one at that, because many unix programmers
> don't fully understand the distinction.

Actually, I find suid/sgid very easy to understand.  They can be explained
in a single sentence.  And implementing program domains as user domains
is necessary in UNIX because of the design.  It might not be a pretty design,
but it works, and (more importantly) doesn't have any fundamental security
problems.

For very security-sensitive applications, this might not be good enough.
enough.  NSA's SELinux has proper program domains and very fine-grained
control over what each program can do.  Internally to the Linux kernel,
there are finer-grained "capabilities", but there's no agreement on
how to map these to the file system.

> Windows is no less confusing, but as Paul pointed out, it is at least
> functional.

Aw, come on. :-)  The UNIX model is pretty functional too.

--
David.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ