Date: Thu, 1 Nov 2001 13:04:56 +0100 From: "Anthony Atkielski" <anthony@atkielski.com> To: "FreeBSD Questions" <freebsd-questions@freebsd.org> Subject: Re: Tiny starter configuration for FreeBSD Message-ID: <009601c162cd$70da3190$0a00000a@atkielski.com> References: <005a01c161ed$a19933c0$1401a8c0@tedm.placo.com> <5.1.0.14.2.20011101165340.02192a40@pop.ozemail.com.au> <005301c162bd$59ac2740$0a00000a@atkielski.com> <006e01c162bf$8c5d87e0$0b64a8c0@becca> <006b01c162c4$c6597cb0$0a00000a@atkielski.com> <20011101224321.H35710@k7.mavetju.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Edwin writes: > Is this true: > > The Windows security is based on who is running > the console. Assuming you mean NT/2000, this is not true. It is possible for multiple people to be logged into the system simultaneously, and indeed there are services (like daemons) that run logged in under other user identities (particularly the special OS identities, one of which is equivalent to the UNIX root) at all times. Additionally, any number of persons may be logged in over the network. However, the design of Windows makes it impossible to log in more than one local, interactive user at a time, since only one user can own the desktop at any given moment, and Windows doesn't support multiple desktops (except in brain-dead ways such as Terminal Server). The NT/2000 kernel is a true multiuser OS, but the Win32 subsystem that drives the local desktop makes this very difficult to see upon casual examination. > There can't be more than one person logged in > at the same time. For the local desktop, this is true, as it is rather like the system console in UNIX. However, any number of people can be logged into the system remotely, or as services (daemons). NT/2000 processes need not be associated with a desktop or console, and it is possible to be logged in without having a process assigned (persons using the http or other services, for example). > If this above is true, it would explain the > reasoning why there are so many different groups > in which you can put people ... Both UNIX and Windows NT/2000 support the notion of groups. > For a Unix-system, if the admin wants to change > something for a user, he often remotely logs in, > makes the changes and logs off. True for NT, also, except that a great many tasks in NT require a GUI, and a local one at that, meaning that not everything can be done remotely, even by someone with authorization to do so, simply because there is no provision for remote GUIs. The traditional solution, in a case like this, has been to use a third-party product like pcANYWHERE to gain control of the local console desktop from a remote location; terribly clumsy and expensive from the standpoint of UNIX, but there isn't much choice. It is one of the great drawbacks to NT. > For a Windows-system, the current user has to > logoff, the admin has to login, make the change, > logoffs and the user logs in again. This can be done remotely without disturbing the local desktop, at least in theory. However, as I've pointed out above, very often some functions absolutely require using the local machine GUI, and for this you have to log in locally (potentially via a crude proxy kludge such as pcANYWHERE). Any local user already on the machine must be kicked off, of course. > Me myself I don't have problems with the one-person= > who-can-do-anything principle because the seperation > in groups is already built-in under Unix (how I see it): It's fine if only one person does all administration. It's a serious problem when the system is administered by a team, particularly when team members are dedicated to specific tasks only. In NT/2000, you can divide administrative responsibility easily and securely among any number of users and groups. > For example we needed a group of people who could > restart a name-daemon. One small script, owned by > user root and group dnsadmin, permissions 4755: Only > people who were in the group dnsadmin could do the task. But the script that does it must change its userid to accomplish the task, because only root can do the deed. Under Windows, you can give permission to do the deed to a completely separate userid or group, and this userid or group can run scripts under its own identity to complete the task. There is never any risk of the script being all-powerful, so even if it were corrupted or turned away from its legitimate use, there would be very little risk of system compromise. For example, in Windows, you can give a user(s) or group(s) permission just to start a service (daemon), and nothing else. So they can write their own script to do this, and the script still won't be able to change passwords or do other special stuff, because it will never execute under an identity with any other permissions. > Maybe your example wasn't well formulated and > you want to do it again? If you work with NT, the limitations of UNIX are glaringly and painfully obvious with respect to security. At the same time, the limitations of NT with respect to remote use and administration are irritating in the extreme once you've worked with UNIX. And if you've worked with Multics, both of these operating systems seem to be lacking in security and flexibility--although few people miss the legendary slowness of Multics, or some of its other failings. > Of course it can be that my examples weren't what > you expected to be, but these are from my experiences > as system administrator who had to walk between > total user-anarchy vs system-security. You do what you can with UNIX, but it's very delicate and very easy to mess up, and some things are simply impossible entirely. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?009601c162cd$70da3190$0a00000a>