Re: securety related question...

On Sat, 5 Oct 2002, Rob Park wrote:

> On Saturday 05 October 2002 05:05 pm, [email protected] wrote:
> > On Sat, 5 Oct 2002, Bob Kimmel wrote:
> > > I asked a question on one of the LFS groups a while back, and someone
> > > told me about the --bind option of mount, which causes the same files
> > > to appear in more than one place in the directory structure.  It seems
> > > to me this feature could be used to create virtual chroot jails - even
> > > if the files needed by a particular app/daemon are dispersed, shared
> > > with other daemons, etc., one could create a jail directory, and then
> > > mount --bind the needed directories within the jail.
> > >
> > > Is this analysis correct?  Are there performance issues with this
> > > approach?  Has anyone done this, thought about doing it, tried it
> > > and found it doesn't work, etc.?  I'd be interested in hearing
> > > opinions...

I do this on my LFS installs for chapters 6 - (almost) 9. I do it to avoid
copy of sources (saving space) while still allowing sources to be avail-
able inside chroot to $LFS. Further, I do the mount as read only, thereby
safegaurding the sources from accidental corruption by any of the root
activities inside the $LFS jail. No problem, no noticed performance
issues.

> >
> > The point of chrooting something is to _deny utterly_ any chance it has of
> > accessing other parts of the filesystem.  If you mount other parts of the
> > filesystem that are in use elsewhere, you _defeat the purpose_ of
> > chrooting.

*chuckle*. I almost agree with this. If you remove the word *utterly*. The
intended purpose is to allow a "redirection" of the root of the tree for a
particular process or application. It has many uses other than denying
access. For instance, the -r parameter to lilo allows running with a set
of files and images different from what it would normally "see". The point
is not to deny access, but to ease "use of". It is only a nice side-effect
that it can be used to deny access, but in programming activities has
*many* other uses.

> Not necessarily. For example, if you had a process that needs /bin and /dev, 
> but you needed to keep it out of /usr, you could chroot it somewhere, then 
> bind bin and dev to there, and it'll do what you want. It'll have access to 
> what it needs, but nothing it doesn't.

An excellent example, much along the lines of what I do for source
archives.

-- 
Bill Maltby
[email protected]

-- 
Unsubscribe: send email to [email protected]
and put 'unsubscribe lfs-security' in the subject header of the message