[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /usr vs. root was: /etc /usr/etc

On Sun, 6 Jul 1997, Yann Dirson wrote:

>  > (a) Installation of the program which belongs to /usr must happen only
>  >     once, on the fileserver providing the /usr partition, without
>  >     changing root partition on workstation, either manually or by a
>  >     script.
> Agreed, this would be fine; but if we can a satisfying solution that
> doesn't satisfy this point, I'll still be OK.
> Just remember all decisions we'll have to take must be based on
> technical issued, and not on other decisions that were already made by
> other people; we should instead understand what the technical issues
> involved in their decisions were.

100% agreed.

>  > 3.a Write a function which will do it (Yann's Solution 1)
>  > =========================================================
>  > 
>  > In this solution, Yann proposes to write the function which will try
>  > to open the needed conffile in /etc, then in /usr/etc, and return the
>  > `FILE *' to the first one found, or NULL if it fails.  Sort of
>  > enhanced fopen().  This function (during the discussion named
>  > confopen()) would be distributed in the package dpkg-dev, or by any
>  > other way, centralized, from Debian ftp site.
> Sorry, I just proposed the concept; when coming to implementation, I
> rather advocate this function be incorporated into libc. That's the
> only way to eventually make it a standard.

Then we must take it to original libc, to not introduce
incompatibilities with our friends.  But I don't think there is a
place in libc for this function -- libc is something standard.

>  >     3. This would require people who get a program from Debian for
>  >        their machine running another Linux distribution (or worse, any
>  >        other i386-based Unix supporting iBCS) to get the driver, or
>  >        forget about the matter.
> The packages' sources will not be changed, so there won't be any
> difference from what wa have now, in this respect. Every distribution
> might use another policy for handling this problem, but if we come
> with such a general solution, they may even be able to use it at a low
> cost.

Well, but then it will act different on other systems.

>  > (b). This will exploit security holes.
> This may be a strong argument against, I do agree.
>  >  For example, there are
>  >      programs which check for shadow passwords by checking if
>  >      /etc/shadow is present.  If the driver redirects it to
>  >      /usr/etc/shadow, which may be taken from intruder's machine, this
>  >      program may give the intruder superuser priveleges (because he
>  >      knows the password).
> How would /usr/etc/whadow come from an intruder machine ? IMO, to do
> that, the intruder would already have gained root priviledges. Or do I
> miss something ?

The mechanism of exploiting is:
1. Bring the fileserver down somehow.
2. Boot up with the IP of the fileserver.
3. Don't tell anyone.

>  > 4. Using patches from kernel 2.1 to mount remote /etc (the Remote /etc
>  > ======================================================================
>  > Solution)
>  > =========
>  > 
>  > There was a proposal to use a patch for unstable Linux kernel 2.1
>  > family to mount remote /etc.  This would lead to various problems.
>  > 
>  > (a) The problems expressed above, in 3.b Yann's Solution 2, problems
>  >     sections (a) 1 to 3.
> 1: false, the mechanism does exist.

In 2.1.  But we must wait for 2.2 (if we want a stable kernel).  So we
virtually don't have it now.

>  > (b) This would require the workstations to have /etc mounted
>  >     read-write, because the administrator of the workstation must be
>  >     able to change, add and remove the files in his /etc directory.
> OK. I already suggested an extension of ACL's, to take into account
> the machine in addition to usual user/group scheme. OK, ACL's aren't
> ready right now.

Yes, ACL seems nice, but it's not ready.

>  > (c) This would require that there will be two copies of machine-local
>  >     config files: one copy on root partition, and the other copy on
>  >     the remote partition, and this would require the administrators to
>  >     keep them updated and identical.
> Why this ? This is exactly what we want to work around with this !

Because we need some files in /etc before we mount remote /etc, or if
it's unavailable (think single-user).

>  > (d) This would make the remote /etc partition very very large, keeping
>  >     up to several thousands of files (on large networks).
> On the server, yes. Isn't it its role ?

Not too ridiculous.  You are in maze of hundreds of little files, all
alike but different.

>  > (e) This will not be secure enough, because root passwords for all the
>  >     workstations will be held in one place, and once the fileserver is
>  >     cracked, the intruder will obtain all the hashed passwords, or
>  >     change them.
> This will not be true when we'll have the machine-ACL extension I
> suggest above (see (b))

Why not?  If you crack the fileserver, I think everything is lost then.

>  > (f) This would require an additional mount point.
> Yes. And ?

We have too many of them.  Anyway, I think remote /etc is not what we
need now.

> You forgot rsync/cfengine, I think. Someone wants to develop about
> this one ?

rsunc or cfengine means changing root filesystem, and that's what I
don't want to do.

> Thanx to you for having gathered all this...

Yes, I'm tired of shouting and arguing, but I think that we have a big
problem, and we must solve it somehow, because otherwise Debian will
stay what it is now -- a perfect OS for a home standalone box, but a
really bad one for large networks.  This isn't the only problem with
Debian, tho...


Vadim Vygonets * vadik@cs.huji.ac.il * vadik@debian.org * Unix admin
The fish doesn't think, because the fish knows...  everything.
	-- Arizona Dream

TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .

Reply to: