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...
Vadik.
--
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: