Re: Sysadmins

[Emmanuel Colbus]

> Message du 03/11/05 18:02
> De : "Leonardo Lopes Pereira" <address@hidden>
> A : address@hidden
> Copie à : address@hidden
> Objet : Re: Sysadmins
> 
> On Thu,  3 Nov 2005 11:50:21 +0100 (CET)
> Emmanuel Colbus <address@hidden> wrote:
> 
> > 
> > Leonardo Lopes Pereira wrote:
> > > After a quick discuss with marco_g on IRC, i started to thing about Why 
> > > we need 
> > > a sysadmin. And I realize that only small options on the system need the 
> > > admin 
> > > interference. I saw that many people here are very fanatic about 
> > > security, but 
> > > what about a system with a admin that put backdoors on programs?
> > > 
> > > So, if we will design a system where people can fell secure, we need to 
> > > create 
> > > a system where the admin has less power as possible.
> > > 
> > > In my opinion, the admin is a user that will be able ONLY to configure 
> > > some 
> > > parts of the system that cannot be configured by a user. All other things 
> > > that 
> > > the admin needs to do, like run a server, will be done by a common user 
> > > with no 
> > > more power than other users.
> > > 
> > > To install programs we can create a mechanism that every user can install 
> > > programs that will be avaliable to every users. but all programs would be 
> > > signed on their origin, and if the user trust on that origin, this 
> > > program will 
> > > be able to work perfectly, if the user doesn't trust on the origin of the 
> > > program it will be alerted about that and will choose how this program 
> > > will 
> > > run. With no access to FS, with a read-only access to FS or if the user 
> > > will 
> > > start to trust on that origin.
> > > 
> > > I know that this is only one case of many thing that a sysadmin does, but 
> > > this 
> > > was what wake up this discuss in my mind, so, if you have more things 
> > > that you 
> > > beleave that only sysadmin can does, we can start to discuss, thanks.
> > 
> > Yes : see http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00827.html 
> > and
> > its thread. 
> > 
> > Btw, allowing (and also forcing) users to install they own software, and 
> > also 
> > administrate it, would only result into a very great amount of lost time 
> > (redundant work from the users), a very bad security (do you really think 
> > every 
> > user has the competence of a sysadmin?), and a waste of disk space and 
> > other 
> > ressources.
> I am not talking about an unix system where only the admin can install 
> softwares 
> on / and the others users intall their softwares on ~. I am talking about a 
> system 
> where all users have the right to add a new package on something like /stow, 
> that 
> will be merged to /. So, If I install a package on that /stow, it will appear 
> to 
> all others users that want to use it.

The only differences with the standard behaviour of the current UNIX I see are 
that
1) it will be far more difficult to manage
2) it will be far more difficult to implement (what if two users install a 
software
with the same name?)
3) it opens a very easy way to make a DoS : just install too much software in 
/stow.

Unfortunately, I see no advantages.

> 
> > If sysadmins were only unneeded parasites, they would have 
> > disappeared for long.
> > 
> > Additionnaly, in the real world, the majority of the users wouldn't 
> > install their own software copy, they would just trust software from some 
> > other
> > person, which is far more dangerous than trusting only one sysadmin (who is
> > identified, available, responsible for what goes wrong, and theoretically 
> > also 
> > competent in his field).
> They can trust in admin and user only admin's prograns, but they can also 
> trust on software installed by others persons.

That's currently also the case.

> 
> > On the other hand, please note that the feature you mentionned is already 
> > available on any UNIX system : just install a copy of the software in your 
> > homedir, and use it instead of the admin's installed version; and use 
> > permission 0755, so that other users may also use it (the only thing you 
> > can't do here is removing its right to access the fs).
> It isn't, not in a secure way.

If you want to prevent the software from accessing the fs, you need a system
with capabilities. I think we all agree that this would be a good thing, but
what would be the advantages of your solution versus a capabilities-using
UNIX? 

> 
> > Oh, and please explain me how you would do to run 1 copy of sshd per user, 
> > for example... all of them sharing port 22 at the same time?! Or only one,
> > which would belong to this "common user"... but how would he have the right
> > to start a shell belonging to another user?
> 
> The sshd will be runned by an common user and when you access the sshd it 
> will ask what user do you wanna user, the password of that user and work like 
> as you access a user by ssh and use the command 'su' to change the user...
> 

Huh?! First, if he has the right to call su, it means that there is a "su" : a
program or a server which has the capability to start a shell belonging to any 
user.
I don't think this is currently one of the Hurd's goals.

Second, this beautiful sshd will need some security patches (did you heard of
the recent http://secunia.com/advisories/17151/, for example?). Who will apply 
them? 
Not the admin : if he has the ability to patch it, he'll be able to add a 
backdoor to read all the passwords, or give him a shell, or whatever he wants. 
So who?

Emmanuel