> >> 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
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
> 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
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,
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, $how) {
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 good for keeping a
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
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 the user
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
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
> > > 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
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 long as we consider
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/$USER
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
I don't
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
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
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 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) {
move
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. But my guess
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, $what, $how) {
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 keeping a bunch of mounts
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
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
> > >>
> > >> - 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
> 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
>
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
}
- 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 way for a filesystem
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 mounts are poorly
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 security
implication of allowing
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
This is by far the biggest
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
in
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) {
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
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
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
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 from the one
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 understood.
And
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 configure
> > 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,
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 :)
Seriously. The
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
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
> > > > 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
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
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 flooding in ;)
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 enough
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 experience. So
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
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 :)
Seriously. The
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, then
> 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
> > 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
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 touching is
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
implication of
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 implication
of
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 understood.
$ whoami
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
- 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
-
To unsubscribe from this list: send the line "unsubscribe
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
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 not
- 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
-
To unsubscribe from this list: send the line unsubscribe
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
miklos
$ mount
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 understood.
$ whoami
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 implication
of
allowing anyone
72 matches
Mail list logo
