This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fixing a security hole in mount table.


Christopher Faylor wrote:
> 
> On Tue, Sep 09, 2003 at 12:12:11AM -0400, Pierre A. Humblet wrote:
> >At 09:11 PM 9/8/2003 -0400, you wrote:
> >>On Mon, Sep 08, 2003 at 08:46:06PM -0400, Pierre A. Humblet wrote:
> >>>This is the first in a series of patches fixing security holes
> >>>associated with the file mappings in the core of Cygwin.
> >>>I hope the explanations below are clear!
> >>
> >>Yes they are, thanks.  I can't comment on the security stuff but
> >>everything else looks good to me.  I'll let Corinna have the final say
> >>on this.
> >>
> >>I wonder if it is time to bite the bullet and get rid of user-mode
> >>mounts entirely.  Or maybe disallow them in suid'ed sessions?  They are
> >>always going to be a security hole AFAICT.
> >
> >Yep, the same thought has crossed my mind.  However I now believe that
> >with the patch the user mounts do not pose a security issue.
> 
> I can't see how a feature which allows any user to redefine what /etc or
> / is could not be a security issue.

We live in an open source environment and there is nothing to prevent a user
from modifying all her programs to use a different / or /etc, or to use a 
peculiar way to access internal Cygwin structures (if accessible).
There only is a security issue when a user can change the behavior of a 
program running as another user. Doing that through the mount table (system 
or user) should now be impossible (assuming Windows ntsec is secure).

It would seem reasonable to prevent user mounts from preempting system mounts.
However when I started thinking about it I realized I was unable to define
what the previous sentence really meant. For example if / is a system mount,
we might not want a user mount to redefine it. But it should be OK to have
a user mount for subdirectories of /, e.g. for /home/pierre.
Similarly we might not want to allow a user mount for /etc. However if we
allow to remount /home/pierre, why would be disallow a user mount for the
file /etc/passwd ?

Pierre


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]