On the Windows side of things, starting from Windows 2000 (i don't count WinNT 
as a real OS anyhow), under a specific DOMAIN, you could define what actions 
each and every user, based on his role, group, the specific computer, or 
almost any other parameter, can do, and cannot do. It's called Group Policy, 
or GPO. 
Although we're a Linux list, knowing our competitors is an advantage, to my 
knowledge, so I'll elaborate a bit further.
in AD, every item is an object, and any group of such items (Aka, one of one 
thousand users, computers, Domain controllers, etc.) are contained in groups 
called Containers.
You have three default policies (which are default, and therefore, quite 
simplistic to begin with) which are Domain Security Policy, Domain Controller 
Security Policy, and Local Security Policy, which control the domain 
server(s) and computers in general, and inside AD Users and Computers, you 
could setup a Group Policy for every container, thus, enforcing predefined  
policies and settings on each member of this container.
You could use it, as a domain administrator, of course, to force installation 
of a specific program(s) on client computers (which are member of this 
container, of course), setup access rights to most parts of Windows settings, 
and applications, enforce settings (I enforced Proxy settings for IE on every 
client computer just yesterday), and do most of whatever comes to your mind.
The GPO is not a trivial issue, and it takes few days to get familiar with it, 
but it is a good central administration tool, and it is a powerfull one 
(although complicated, comparing to their "Administration for the Dummies" 
method of doing things).
Not an MS lover (hell, not at all), I can say it's a great tool, and it is a 
very usefull one, too.
Don't underestimate this you do not know.

Ez.

On Sunday 08 February 2004 18:58, Arik Baratz wrote:
> -----Original Message-----
> From: Mark Veltzer [mailto:[EMAIL PROTECTED]
>
> > 1. The operating system does not, per se, state which applications each
> > user can run. If a user has running capabilities then he can launch any
> > executable file. Even an executable file which was derived from
> > consulting some greek all knowing oracle who can program in binary.
>
> Nope. It is definitely possible.
>
> Using group permissions, it is possible to define different levels of users
> who can run different applications depending on their group membership. All
> that's needed to do is:
>
> A. put the users in relevant groups
> B. restrict execute access to the binaries to the relevant groups
> C. prevent the users from running their own binaries, by restricting
> execution rights to disk space they can write into
>
> > 2. The desktop may hide some buttons but this is no guaratee what so ever
> > that the user wont be able to launch an application. You better look at
> > buttons as fast ways of doing things and not as "you can/can't"
> > separators. This is not windows we are talking about.
>
> You can limit access to the actual binaries, see my previous response.
>
> > 3. No set of standard desktop applications has been certified as "not
> > allowing in some strage way to launch a shell" since launching a shell is
> > absolutely allowed in Linux (and encouraged for that matter).
>
> If your application dictates it, you can indeed restrict a user from
> running a shell, using the mechanism disscussed before.
>
> > 4. If you take konqueror for example, it will allow you to have a shell
> > running inside it.
>
> Konq. still needs to run the actual shell, and it runs under the UID of the
> launching user, so any restrictions you put on the shell will be reflected
> by Knoq.
>
> > 5. The number of ways you could manipulate an application to launch a
> > shell for you is so numerous that I can't really think of a large GUI
> > application which I CANT launch a shell from by manipulating it in some
> > way.
>
> If you limit access to the actual shell executables on your system and make
> sure everything the user runs is with his own privileges, you can do it. It
> takes work but very possible, I say 1-2 days of tinkering.
>
> > 6. If this entire concept of yours is some marketing peoples idea for
> > "the users not touching our system" go back to them and tell them it's a
> > dream
>
> On the contrary, it is very possible, and I have seen it done more than
> once on various free-shell accounts and other places.
>
> > 7. GDM is just the login application and does not control what the user
> > sees or does not see on his desktop. The user can even login from GDM to
> > a KDE environment.
>
> Agree.
>
> > BTW: just for the record - the situation in windows is a lot worse since
> > in most windows distributions the user has installation priveleges on the
> > machine so he can actually halt the machine (for instance by running an
> > installation process which removes critical files) or render the machine
> > unbootable. In Linux he could just launch applications and not hurt
> > anyone but himself. Quite an improvement.
>
> Actually Microsoft has enough tools to make it possible. Indeed the
> original configuration NT (4.0 and above) comes with does define the global
> user Everyone with permission to most of the hard-drive, but it is very
> possible to build a machine with the correct permission-set.
>
> Oh, yes, and disable the RunAs service.
>
> -- Arik
>
> **********************************************************************
> This email and attachments have been scanned for
> potential proprietary or sensitive information leakage.
>
> PortAuthority(TM)  Server
> Keeping Information Inside
> Vidius, Inc.
> www.vidius.com
> **********************************************************************
>
>
> 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]


=================================================================
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]

Reply via email to