> >> Arn't there ways to escape chroot jails? Serge had pointed me to a URL
> >> which showed chroots can be escaped. And if that is true than having all
> >> user's private mount tree in the same namespace can be a security issue?
> >
> > No. In fact chrooting the user into /share/$USER will actu
Miklos Szeredi <[EMAIL PROTECTED]> writes:
>> Arn't there ways to escape chroot jails? Serge had pointed me to a URL
>> which showed chroots can be escaped. And if that is true than having all
>> user's private mount tree in the same namespace can be a security issue?
>
> No. In fact chrooting th
> Arn't there ways to escape chroot jails? Serge had pointed me to a URL
> which showed chroots can be escaped. And if that is true than having all
> user's private mount tree in the same namespace can be a security issue?
No. In fact chrooting the user into /share/$USER will actually
_grant_ a p
On Fri, 2007-04-13 at 16:05 +0200, Miklos Szeredi wrote:
> > > Thinking a bit more about this, I'm quite sure most users wouldn't
> > > even want private namespaces. It would be enough to
> > >
> > > chroot /share/$USER
> > >
> > > and be done with it.
> > >
> > > Private namespaces are only
On Fri, 2007-04-13 at 13:58 +0200, Miklos Szeredi wrote:
> > On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
> > > > 1. clone the master namespace.
> > > >
> > > > 2. in the new namespace
> > > >
> > > > move the tree under /share/$me to /
> > > > for each ($user, $what,
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > Agreed on desired behavior, but not on chroot sufficing. It actually
> > > > sounds like you want exactly what was outlined in the OLS paper.
> > > >
> > > > Users still need to be in a different mounts namespace from the admin
> > > > user so l
> > > Agreed on desired behavior, but not on chroot sufficing. It actually
> > > sounds like you want exactly what was outlined in the OLS paper.
> > >
> > > Users still need to be in a different mounts namespace from the admin
> > > user so long as we consider the deluser and backup problems
> >
> > Thinking a bit more about this, I'm quite sure most users wouldn't
> > even want private namespaces. It would be enough to
> >
> > chroot /share/$USER
> >
> > and be done with it.
>
> I don't think so. How to you want to implement non-shared /tmp
> directories?
mount --bind /.tmp/$US
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > Thinking a bit more about this, I'm quite sure most users wouldn't
> > > even want private namespaces. It would be enough to
> > >
> > > chroot /share/$USER
> > >
> > > and be done with it.
> > >
> > > Private namespaces are only good for keep
On Fri, Apr 13, 2007 at 01:58:59PM +0200, Miklos Szeredi wrote:
> > On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
> > > > 1. clone the master namespace.
> > > >
> > > > 2. in the new namespace
> > > >
> > > > move the tree under /share/$me to /
> > > > for each ($user,
> > Thinking a bit more about this, I'm quite sure most users wouldn't
> > even want private namespaces. It would be enough to
> >
> > chroot /share/$USER
> >
> > and be done with it.
> >
> > Private namespaces are only good for keeping a bunch of mounts
> > referenced by a group of processes
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
> > > > 1. clone the master namespace.
> > > >
> > > > 2. in the new namespace
> > > >
> > > > move the tree under /share/$me to /
> > > > for each ($user, $what, $how) {
> > >
> On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
> > > 1. clone the master namespace.
> > >
> > > 2. in the new namespace
> > >
> > > move the tree under /share/$me to /
> > > for each ($user, $what, $how) {
> > > move /share/$user/$what to /$what
> > > if ($
On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
> > 1. clone the master namespace.
> >
> > 2. in the new namespace
> >
> > move the tree under /share/$me to /
> > for each ($user, $what, $how) {
> > move /share/$user/$what to /$what
> > if ($how == slave)
Quoting Ian Kent ([EMAIL PROTECTED]):
> On Wed, 2007-04-11 at 09:26 -0500, Serge E. Hallyn wrote:
> > Quoting Ian Kent ([EMAIL PROTECTED]):
> > > On Wed, 2007-04-11 at 12:48 +0200, Miklos Szeredi wrote:
> > > > > > >>
> > > > > > >> - users can use bind mounts without having to pre-configure them
On Wed, 2007-04-11 at 09:26 -0500, Serge E. Hallyn wrote:
> Quoting Ian Kent ([EMAIL PROTECTED]):
> > On Wed, 2007-04-11 at 12:48 +0200, Miklos Szeredi wrote:
> > > > > >>
> > > > > >> - users can use bind mounts without having to pre-configure them in
> > > > > >> /etc/fstab
> > > > > >>
> > > >
Quoting Ian Kent ([EMAIL PROTECTED]):
> On Wed, 2007-04-11 at 12:48 +0200, Miklos Szeredi wrote:
> > > > >>
> > > > >> - users can use bind mounts without having to pre-configure them in
> > > > >> /etc/fstab
> > > > >>
> > > >
> > > > This is by far the biggest concern I see. I think the secur
On Wed, 2007-04-11 at 12:48 +0200, Miklos Szeredi wrote:
> > > >>
> > > >> - users can use bind mounts without having to pre-configure them in
> > > >> /etc/fstab
> > > >>
> > >
> > > This is by far the biggest concern I see. I think the security
> > > implication of allowing anyone to do bind
> > >>
> > >> - users can use bind mounts without having to pre-configure them in
> > >> /etc/fstab
> > >>
> >
> > This is by far the biggest concern I see. I think the security
> > implication of allowing anyone to do bind mounts are poorly understood.
>
> And especially so since there is no
> 1. clone the master namespace.
>
> 2. in the new namespace
>
> move the tree under /share/$me to /
> for each ($user, $what, $how) {
> move /share/$user/$what to /$what
> if ($how == slave) {
> make the mount tree under /$what as slave
>
On Mon, Apr 09, 2007 at 10:46:25AM -0700, Ram Pai wrote:
> On Mon, 2007-04-09 at 12:07 -0500, Serge E. Hallyn wrote:
> > Quoting Miklos Szeredi ([EMAIL PROTECTED]):
>
> > > - need to set up mount propagation from global namespace to private
> > >ones, mount(8) does not yet have options to con
On Mon, 2007-04-09 at 22:10 +0200, Miklos Szeredi wrote:
> > > The one in pam-0.99.6.3-29.1 in opensuse-10.2 is totally broken. Are
> > > you interested in the details? I can reproduce it, but forgot to note
> > > down the details of the brokenness.
> >
> > I don't know how far removed that is f
> > The one in pam-0.99.6.3-29.1 in opensuse-10.2 is totally broken. Are
> > you interested in the details? I can reproduce it, but forgot to note
> > down the details of the brokenness.
>
> I don't know how far removed that is from the one being used by redhat,
> but assuming it's the same, the
> On 4/6/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> > Jan Engelhardt wrote:
> > > On Apr 6 2007 16:16, H. Peter Anvin wrote:
> > - users can use bind mounts without having to pre-configure them in
> > /etc/fstab
> >
> > >> This is by far the biggest concern I see. I think the s
> > > > One thing that is missing from this series is the ability to restrict
> > > > user mounts to private namespaces. The reason is that private
> > > > namespaces have still not gained the momentum and support needed for
> > > > painless user experience. So such a feature would not yet get en
On Mon, 2007-04-09 at 12:07 -0500, Serge E. Hallyn wrote:
> Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > - need to set up mount propagation from global namespace to private
> >ones, mount(8) does not yet have options to configure propagation
>
> Hmm, I guess I get lost using my own little
> > This patchset adds support for keeping mount ownership information in
> > the kernel, and allow unprivileged mount(2) and umount(2) in certain
> > cases.
>
> No replies, huh?
All we need is a comment from Andrew, and the replies come flooding in ;)
> My knowledge of the code which you're tou
On Fri, 2007-04-06 at 16:16 -0700, H. Peter Anvin wrote:
> >>
> >> - users can use bind mounts without having to pre-configure them in
> >> /etc/fstab
> >>
>
> This is by far the biggest concern I see. I think the security
> implication of allowing anyone to do bind mounts are poorly understoo
Ram Pai wrote:
>
> It is in FC6. I dont know the status off upstream util-linux. I did
> submit the patch many times to Adrian Bunk (the then util-linux
> maintainer) and got no response. I have not pushed the patches to the
> new maintainer(Karel Zak?) though.
>
Well, do that, then :)
Seriousl
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > > > One thing that is missing from this series is the ability to restrict
> > > > > user mounts to private namespaces. The reason is that private
> > > > > namespaces have still not gained the momentum and support needed for
> > > > > painless user
Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > > This patchset adds support for keeping mount ownership information in
> > > the kernel, and allow unprivileged mount(2) and umount(2) in certain
> > > cases.
> >
> > No replies, huh?
>
> All we need is a comment from Andrew, and the replies come f
On 4/6/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
> Jan Engelhardt wrote:
> > On Apr 6 2007 16:16, H. Peter Anvin wrote:
> - users can use bind mounts without having to pre-configure them in
> /etc/fstab
>
> >> This is by far the biggest concern I see. I think the security
> >>
Jan Engelhardt wrote:
> On Apr 6 2007 16:16, H. Peter Anvin wrote:
- users can use bind mounts without having to pre-configure them in
/etc/fstab
>> This is by far the biggest concern I see. I think the security implication
>> of
>> allowing anyone to do bind mounts are poorly unde
On Apr 6 2007 16:16, H. Peter Anvin wrote:
>> >
>> > - users can use bind mounts without having to pre-configure them in
>> > /etc/fstab
>> >
>
> This is by far the biggest concern I see. I think the security implication of
> allowing anyone to do bind mounts are poorly understood.
$ whoami
mi
>>
>> - users can use bind mounts without having to pre-configure them in
>> /etc/fstab
>>
This is by far the biggest concern I see. I think the security
implication of allowing anyone to do bind mounts are poorly understood.
-hpa
___
Contai
On Wed, 04 Apr 2007 20:30:12 +0200 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> This patchset adds support for keeping mount ownership information in
> the kernel, and allow unprivileged mount(2) and umount(2) in certain
> cases.
No replies, huh?
My knowledge of the code which you're touching is
36 matches
Mail list logo
