On Thu, 7 Aug 2008, Serge E. Hallyn wrote: > Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > > "Serge E. Hallyn" <serue@xxxxxxxxxx> writes: > > > so on the bright side I pulled this tree today and it compiled and > > > passed ltp with no problems. > > > > > > But then I played around a bit and found I could do the following: > > > > > > (hmm, i'm trying to remember the exact order :) > > > > > > as root: > > > mmount --bind -o user=500 /home/hallyn/etc/ /home/hallyn/etc/ > > > mount --bind /mnt /mnt > > > mount --make-rshared /mnt > > > mount --bind /dev /mnt/dev > > > > > > as hallyn: > > > mmount --bind /mnt /home/hallyn/etc/mnt > > > /usr/src/mmount-0.3/mmount --bind mnt/dev mnt/src > > > > You are using relative directory names here which makes it confusing. > > I'm assuming you in /home/hallyn/etc ? > > Sorry, yeah. > > > > Now /mnt/src contained /dev. > > > > > > Is this what we want? > > > > I don't think so. > > > > I think the simplest answer is to not allow mounting of shared > > subtrees controlled by a different user. > > > > Serge I think you are right downgrading the mount from shared to slave > > looks like the sane thing to do if the mount owners match. > > I assume you mean "if the mount owners don't match"? > > Miklos, what do you think? Sorry about the late reply: I was on a long summer vacation... Serge, thanks for spotting this: it looks indeed a nasty hole! I also agree about the solution. > The next question then becomes, how can we prove to ourselves that that > closes the last security hole with unprivileged mounts? So long as > we treat each mount event as a piece of information and look at it as an > information flow problem, maybe we can actually come up with a good > description of the logic that is implemented and show that there is no > way a user can "leak" info... (where a leak is a mount event, a > violation of intended DAC on open(file) or mkdir, etc) "Information flow problem" doesn't mean much to me (I'm actually an electric engineer, who ended up doing programming for living ;) But yeah, we should think this over very carefully. Especially interaction with mount propagation, which has very complicated and sometimes rather counter-intuitive semantics. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
