Well then, I'm just not the type. I'll elaborate.
On Tuesday 10 February 2004 10:32, Oron Peled wrote:
> On Tuesday 10 February 2004 05:28, Ez-Aton wrote:
> > ... starting from Windows 2000 (i don't count WinNT as a real OS anyhow),
>
> First an unrelated observation. Through the years I used to hear:
> "Windows for Worgroups isn't real OS -- Win95 is true 32bit OS"
> "Win9X is just a graphical shell -- WinNT is modern design done
> by the same people who did VMS"
> "WinNT is obsolete -- W2K is the future"
>
> and I'm waiting for:
> "W2K is the old world OS -- W2K server and .Net are true revolution"
>
> This isn't against you specifically Ez, every Win* user I know thinks
> the *previous* Windows sucks big time... isn't it weird?
Not exactly. For some time now, Windows 2003 Server is at hand, and I still
claim Windows 2000 to be a good product (generally speaking). Windows 2000
Server implements the AD mechanism (unlike Win2000 Pro), but it's not a
kernel based part, but a module, you can run the system without (AD
Maintenance mode).
>
> Personally I'll take any day my first old slackware (kernel 0.99pl14)
> with its FVWM (with GoodStuff config) -- it was functional, fast and
> stable.
>
> And now to the important subject...
>
> > Although we're a Linux list, knowing our competitors is an advantage, to
> > my knowledge,
>
> Agreed (at least by me).
>
> > in AD, ... [description of ActiveDirectory relevant part]
>
> Organization of various settings in a global hierarchy is an important
> feature that generally eases administration. I'd like to put it in some
> perspective:
> 1. Sometimes a valid idea is designed badly -- The famous example
> is the Windwos Registry which had the same hierarchical organization
> but was designed as monolithic binary file which everyone need
> to access... not a pretty sight.
Nowdays, Registry resides in three files, each one is a special "branch" or
"hive" - System, Software, Users, and each user has his/her own registry part
inside his homedir (a user.dat file in ~/)
>
> Note: the utmp/wtmp in Unix/linux present exactly the same design mistake
> which explains the low validity of data you find there...
>
> 2. As a counter-example you may look at Linux GConf -- basically it's
> the registry idea done the right way: decouple storage from interface
> (curret plugins are XML, but that may be change), not a single
> repositoty but several configurable ones (system-wide, per-user,
> etc.), fits nicely with the regular permission model (each user has its own
> gconfd, no suid access).
Never did try. Can't say anything about it.
>
> 3. For site-wide hierarchical management many use LDAP. It is already
> integrated in the important infrastructural applications -- login,
> (via pam) Mail (sendmail, postfix, imap4, etc.) and more.
Agree. But it's not the native way of doing things, yet. Implementing an LDAP
schema is based on picking up the correct schema, while, although it reduces
the choise, AD (which is based on LDAP and Kerberos) has already built-in
schema.
>
> But one of your points is that this isn't integrated into every application
> or the kernel (god forbid :-) like AD is in Windows. I'll try to
> refer to this point later.
It is not integrated into the kernel in Windows either.
>
> > ... setup access rights to most parts of Windows settings,
> > and applications, enforce settings ...
>
> This is a very important issue. The Linux kernel has implemented
> internally capability based security for quite some time. However,
> almost no one uses it.
True. Ever asked why?
>
> I think one of the problems we have in attaching security information
> to the user login, is that there are many cases of "non-login" usage:
> - Someone is running a process via rsh/ssh (this isn't login).
> - Someone is using my DISPLAY (consuming resources).
> - Someone is using my disk via NFS (again,... resources).
> - Packets are being routed via my computer (there are no "user"
> credentials in the packets at all..)
Agree.
>
> Let's combine the above points into a real-life scenario:
> I seat at computer A running via SSH a program on computer B
> (with its DISPLAY apears on A of course). The program was
> loaded from my NFS server C and establish a connection
> to a server D, and the packets are routed through router E.
>
> Now since the user activity is distributed, it's non-trivial
> to apply some central policy to his actions.
>
Not exactly. You could, through a central LDAP/other directory, which
Computers A, B & C are to AAA agains, the rules which apply to a specific
user/computer. If you're permitted to use DISPLAY on other computer, but
allowed to run only X,Y &Z, that's what you'll run (Computer B now). Computer
A asks if it's allowed to show DISPLAY, for who and from where, Computer B
checks if you're allowed to run the software you're running, your server, D,
checks what are your permissions regarding NFS, quota, etc, and computer E
checks the source, target, and may be given details about your UID. If all
computers are checking agains a directory located on computer F (with live
replica to computer G), you could and should be able to maintain one security
and permission directory service and tables, and no more. That's good for an
organization.
> You are correct that having a central policy helps. But the hard
> question is if we can do it *without* sacrification of our
> distributed world ("The network is the computer" [McNeily]).
No. See above.
>
> > (I enforced Proxy settings for IE on every client computer just
> > yesterday),
>
> I'm not sure I understand what you mean by "enforced". Does it change the
> settings in the Explorer preferences? Than this is not enforcement because
> it depends on the cooperation of the Explorer program -- What would prevent
> a user modifing the behaviour of Explorer? security by obscurity.
It changes the settings per computer in my Domain. Yes. You had proxy settings
ten minutes ago, now you don't. You can't change them back (if I decide you
can't), and even if you could, give the computer then minutes on the net, and
they'll be back to what I've predefined. That's the power of the GPO.
> The correct place to enforce proxy settings is the firewall regardless
> of the OS.
How do you force Proxy (actually, in my case - no-proxy) settings for your
clients on the firewall? Had I used a proxy, I could implement a transparent
proxy, however, I didn't want them to use a proxy anyhow...
>
> A Linux note:
> The "old way" to set proxy was via environment variables -- this had the
> excelent effect that you can do it at whatever level you want:
> - For every user -- in system login scripts.
> - For a single user -- in his own login script.
> - For a single session -- on the command line.
> The only downside was you have to start the application for it to take
> effect. I wonder why modern browsers haven't left it as a *default*.
> Of course if they use GConf, we can still have these properties.
True. I agree. The environment variable is a good tool, although limited. You
can hardly prevent a user from overaiding your settings. I don't know GConf
yet, so I can't commetn about it.
>
> > and do most of whatever comes to your mind.
>
> Can you run scripts? If not, than it's good only for the simple cases of
> variable=value settings and not places where you need to run some logic.
> (It's true that most settings are these simple var=value cases).
You can run scripts. CMD scripts, VBS scripts, and if clients can run
perl/python/BASh, these too. You can run executebles on client computers,
because inside an organization, there (must be) is a trust relationship.
I'm not saying LDAP on a Linux machine is a bad thing, however I'm saying that
on Win2k, and using their reemplementation of the LDAP into the AD mechanism,
they did a good job. Not perfect, but a good one, towards central point of
control in an organization. We should learn from their successes, and from
their mistakes, towards doing what we do better.
Ez.
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
