On Wed, Jun 27, 2001 at 11:14:13 -0700, "H. Peter Anvin" wrote:
> > > If we only allow user chroots for processes that have never been
> > > chrooted before, and if the suid/sgid bits won't have any effect under
> > > the new root, it should be perfectly safe to allow any user to chroot.
> >
> >
On Wed, Jun 27, 2001 at 11:14:13 -0700, H. Peter Anvin wrote:
If we only allow user chroots for processes that have never been
chrooted before, and if the suid/sgid bits won't have any effect under
the new root, it should be perfectly safe to allow any user to chroot.
Hmm. Dos this
Sean Hunter writes:
> On Wed, Jun 27, 2001 at 04:55:56PM -0400, Albert D. Cahalan wrote:
>> ln /dev/zero /tmp/zero
>> ln /dev/hda ~/hda
>> ln /dev/mem /var/tmp/README
>
> None of these (of course) work if you use mount options to
> restrict device nodes on those filesystems.
In which case, you
On Wed, Jun 27, 2001 at 04:55:56PM -0400, Albert D. Cahalan wrote:
> ln /dev/zero /tmp/zero
> ln /dev/hda ~/hda
> ln /dev/mem /var/tmp/README
None of these (of course) work if you use mount options to restrict device
nodes on those filesystems.
Sean
-
To unsubscribe from this list: send the
[EMAIL PROTECTED] (H. Peter Anvin) wrote on 27.06.01 in
<9hd7pl$86f$[EMAIL PROTECTED]>:
> By author:[EMAIL PROTECTED] (Kai Henningsen)
> > [EMAIL PROTECTED] (Jorgen Cederlof) wrote on 27.06.01 in
> > <20010627014534.B2654@ondska>:
> >
> > > If we only allow user chroots for processes
[EMAIL PROTECTED] (H. Peter Anvin) wrote on 27.06.01 in
9hd7pl$86f$[EMAIL PROTECTED]:
By author:[EMAIL PROTECTED] (Kai Henningsen)
[EMAIL PROTECTED] (Jorgen Cederlof) wrote on 27.06.01 in
20010627014534.B2654@ondska:
If we only allow user chroots for processes that have never
On Wed, Jun 27, 2001 at 04:55:56PM -0400, Albert D. Cahalan wrote:
ln /dev/zero /tmp/zero
ln /dev/hda ~/hda
ln /dev/mem /var/tmp/README
None of these (of course) work if you use mount options to restrict device
nodes on those filesystems.
Sean
-
To unsubscribe from this list: send the line
Sean Hunter writes:
On Wed, Jun 27, 2001 at 04:55:56PM -0400, Albert D. Cahalan wrote:
ln /dev/zero /tmp/zero
ln /dev/hda ~/hda
ln /dev/mem /var/tmp/README
None of these (of course) work if you use mount options to
restrict device nodes on those filesystems.
In which case, you can't
> Not that the documentation on MAP_ANON is any good either
> but at least the mere existence of the flag is mentioned.
> Seriously:
> both features ought to be documented in the man pages
> (I did submit a man page too, back in 1996)
Ah yes, I see. We both wrote a man page, and each contained
H. Peter Anvin writes:
> "Albert D. Cahalan" wrote:
>> BTW, it is way wrong that /dev/zero should be needed at all.
>> Such use is undocumented ("man zero", "man mmap") anyway, and
>> AFAIK one should use mmap() with MAP_ANON instead. Not that
>> the documentation on MAP_ANON is any good either,
"Albert D. Cahalan" wrote:
>
> BTW, it is way wrong that /dev/zero should be needed at all.
> Such use is undocumented ("man zero", "man mmap") anyway, and
> AFAIK one should use mmap() with MAP_ANON instead. Not that
> the documentation on MAP_ANON is any good either, but at least
> the mere
H. Peter Anvin writes:
> Albert D. Cahalan wrote:
>> Normal users can use an environment provided for them.
>>
>> While trying to figure out why the "heyu" program would not
>> work on a Red Hat box, I did just this. As root I set up all
>> the device files needed, along Debian libraries and the
Followup to: <83fdx$[EMAIL PROTECTED]>
By author:[EMAIL PROTECTED] (Kai Henningsen)
In newsgroup: linux.dev.kernel
>
> [EMAIL PROTECTED] (Jorgen Cederlof) wrote on 27.06.01 in
><20010627014534.B2654@ondska>:
>
> > If we only allow user chroots for processes that have never been
> >
Jesse Pollard wrote:
>2. Any penetration is limited to what the user can access.
Sure, but in practice, this is not a limit at all.
Once a malicious party gains access to any account on your
system (root or non-root), you might as well give up, on all
but the most painstakingly careful
[EMAIL PROTECTED] ("H. Peter Anvin") writes:
> Followup to: <20010627014534.B2654@ondska>
> By author:Jorgen Cederlof <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> > If we only allow user chroots for processes that have never been
> > chrooted before, and if the suid/sgid bits
[EMAIL PROTECTED] ("H. Peter Anvin") writes:
> Followup to: <20010627014534.B2654@ondska>
> By author:Jorgen Cederlof <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> > If we only allow user chroots for processes that have never been
> > chrooted before, and if the suid/sgid bits
On 27 Jun 2001, David Wagner wrote:
>
> Why is it useless? It sounds useful to me, on first glance. If I want
> to run a user-level network daemon I don't trust (for instance, fingerd),
> isolating it in a chroot area sounds pretty nice: If there is a buffer
> overrun in the daemon, you can
[EMAIL PROTECTED] (David Wagner):
> H. Peter Anvin wrote:
> >By author:Jorgen Cederlof <[EMAIL PROTECTED]>
> >> If we only allow user chroots for processes that have never been
> >> chrooted before, and if the suid/sgid bits won't have any effect under
> >> the new root, it should be
On 27 Jun 2001, David Wagner wrote:
> H. Peter Anvin wrote:
> >By author:Jorgen Cederlof <[EMAIL PROTECTED]>
> >> If we only allow user chroots for processes that have never been
> >> chrooted before, and if the suid/sgid bits won't have any effect under
> >> the new root, it should be
On Wed, 27 Jun 2001, Chris Wedgwood wrote:
> On Tue, Jun 26, 2001 at 09:40:36PM -0400, Alexander Viro wrote:
>
> > You need /dev/zero to get anywhere near the normal behaviour of the
> > system.
>
> Not commenting on the original patch, I think requiring /dev/zero for
> a 'usable' system
On Tue, Jun 26, 2001 at 09:40:36PM -0400, Alexander Viro wrote:
> You need /dev/zero to get anywhere near the normal behaviour of the
> system.
Not commenting on the original patch, I think requiring /dev/zero for
a 'usable' system should be considered a [g]libc bug. /dev/zero should
be
[EMAIL PROTECTED] (H. Peter Anvin) wrote on 26.06.01 in <[EMAIL PROTECTED]>:
> Albert D. Cahalan wrote:
>
> >
> > Normal users can use an environment provided for them.
> >
> > While trying to figure out why the "heyu" program would not
> > work on a Red Hat box, I did just this. As root I set
[EMAIL PROTECTED] (Jorgen Cederlof) wrote on 27.06.01 in
<20010627014534.B2654@ondska>:
> If we only allow user chroots for processes that have never been
> chrooted before, and if the suid/sgid bits won't have any effect under
> the new root, it should be perfectly safe to allow any user to
[EMAIL PROTECTED] (H. Peter Anvin) wrote on 26.06.01 in [EMAIL PROTECTED]:
Albert D. Cahalan wrote:
Normal users can use an environment provided for them.
While trying to figure out why the heyu program would not
work on a Red Hat box, I did just this. As root I set up all
the
[EMAIL PROTECTED] (Jorgen Cederlof) wrote on 27.06.01 in
20010627014534.B2654@ondska:
If we only allow user chroots for processes that have never been
chrooted before, and if the suid/sgid bits won't have any effect under
the new root, it should be perfectly safe to allow any user to
On Tue, Jun 26, 2001 at 09:40:36PM -0400, Alexander Viro wrote:
You need /dev/zero to get anywhere near the normal behaviour of the
system.
Not commenting on the original patch, I think requiring /dev/zero for
a 'usable' system should be considered a [g]libc bug. /dev/zero should
be present,
On Wed, 27 Jun 2001, Chris Wedgwood wrote:
On Tue, Jun 26, 2001 at 09:40:36PM -0400, Alexander Viro wrote:
You need /dev/zero to get anywhere near the normal behaviour of the
system.
Not commenting on the original patch, I think requiring /dev/zero for
a 'usable' system should be
On 27 Jun 2001, David Wagner wrote:
H. Peter Anvin wrote:
By author:Jorgen Cederlof [EMAIL PROTECTED]
If we only allow user chroots for processes that have never been
chrooted before, and if the suid/sgid bits won't have any effect under
the new root, it should be perfectly safe to
On 27 Jun 2001, David Wagner wrote:
Why is it useless? It sounds useful to me, on first glance. If I want
to run a user-level network daemon I don't trust (for instance, fingerd),
isolating it in a chroot area sounds pretty nice: If there is a buffer
overrun in the daemon, you can get
[EMAIL PROTECTED] (David Wagner):
H. Peter Anvin wrote:
By author:Jorgen Cederlof [EMAIL PROTECTED]
If we only allow user chroots for processes that have never been
chrooted before, and if the suid/sgid bits won't have any effect under
the new root, it should be perfectly safe to
[EMAIL PROTECTED] (H. Peter Anvin) writes:
Followup to: 20010627014534.B2654@ondska
By author:Jorgen Cederlof [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
If we only allow user chroots for processes that have never been
chrooted before, and if the suid/sgid bits won't have any
Followup to: 83fdx$[EMAIL PROTECTED]
By author:[EMAIL PROTECTED] (Kai Henningsen)
In newsgroup: linux.dev.kernel
[EMAIL PROTECTED] (Jorgen Cederlof) wrote on 27.06.01 in
20010627014534.B2654@ondska:
If we only allow user chroots for processes that have never been
chrooted before,
H. Peter Anvin writes:
Albert D. Cahalan wrote:
Normal users can use an environment provided for them.
While trying to figure out why the heyu program would not
work on a Red Hat box, I did just this. As root I set up all
the device files needed, along Debian libraries and the heyu
Albert D. Cahalan wrote:
BTW, it is way wrong that /dev/zero should be needed at all.
Such use is undocumented (man zero, man mmap) anyway, and
AFAIK one should use mmap() with MAP_ANON instead. Not that
the documentation on MAP_ANON is any good either, but at least
the mere existence of
H. Peter Anvin writes:
Albert D. Cahalan wrote:
BTW, it is way wrong that /dev/zero should be needed at all.
Such use is undocumented (man zero, man mmap) anyway, and
AFAIK one should use mmap() with MAP_ANON instead. Not that
the documentation on MAP_ANON is any good either, but at least
Mohammad A. Haque wrote:
>Why do this in the kernel when it's available in userspace?
Because the userspace implementations aren't equivalent.
In particular, it is not so easy for them to enforce the following
restriction:
(*) If a non-root user requested the chroot, then setuid/setgid
Albert D. Cahalan wrote:
>
> Normal users can use an environment provided for them.
>
> While trying to figure out why the "heyu" program would not
> work on a Red Hat box, I did just this. As root I set up all
> the device files needed, along Debian libraries and the heyu
> executable itself.
H. Peter Anvin writes:
> [somebody]
>> Have you ever wondered why normal users are not allowed to chroot?
>>
>> I have. The reasons I can figure out are:
>>
>> * Changing root makes it trivial to trick suid/sgid binaries to do
>> nasty things.
>>
>> * If root calls chroot and changes uid, he
>
>You need to be root to do mknod. You need to do mknod to create /dev/zero.
>You need /dev/zero to get anywhere near the normal behaviour of the system.
>
Sure, but we're not necessarily looking for a system that behaves
normally in all aspects. The example given was that of a paranoid
On Tue, 26 Jun 2001, Paul Menage wrote:
> But only root can set this up, since you currently have to be root in
> order to chroot(). The (only) advantage of the user chroot() patch would
> be that users would be able to do the same thing without root
> intervention.
You need to be root to do
>Paul Menage wrote:
>> This could be regarded as the wrong way to solve such a problem, but
>> this kind of bug seems to be occurring often enough on BugTraq that it
>> might be useful if you don't have the resources to do a full security
>> audit on your program (or if the source to some of your
Paul Menage wrote:
> This could be regarded as the wrong way to solve such a problem, but
> this kind of bug seems to be occurring often enough on BugTraq that it
> might be useful if you don't have the resources to do a full security
> audit on your program (or if the source to some of your
It is not rocket science to populate a chroot environment with enough
files to make many interesting applications work. Don't expect a general
solution---chroot is not a silver bullet---but it is useful. (Note also
that whether you can populate a chroot environment sufficiently is roughly
Paul Menage wrote:
>It could potentially be useful for a network daemon (e.g. a simplified
>anonymous FTP server) that wanted to be absolutely sure that neither it
>nor any of its libraries were being tricked into following a bogus
>symlink, or a "/../" in a passed filename. After
H. Peter Anvin wrote:
>By author:Jorgen Cederlof <[EMAIL PROTECTED]>
>> If we only allow user chroots for processes that have never been
>> chrooted before, and if the suid/sgid bits won't have any effect under
>> the new root, it should be perfectly safe to allow any user to chroot.
>
>Safe,
Followup to: <[EMAIL PROTECTED]>
By author:Paul Menage <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> It could potentially be useful for a network daemon (e.g. a simplified
> anonymous FTP server) that wanted to be absolutely sure that neither it
> nor any of its libraries were
In article <[EMAIL PROTECTED]>,
you write:
>
>Safe, perhaps, but also completely useless: there is no way the user
>can set up a functional environment inside the chroot. In other
>words, it's all pain, no gain.
>
It could potentially be useful for a network daemon (e.g. a simplified
anonymous
Followup to: <20010627014534.B2654@ondska>
By author:Jorgen Cederlof <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Have you ever wondered why normal users are not allowed to chroot?
>
> I have. The reasons I can figure out are:
>
> * Changing root makes it trivial to trick
Hi,
Have you ever wondered why normal users are not allowed to chroot?
I have. The reasons I can figure out are:
* Changing root makes it trivial to trick suid/sgid binaries to do
nasty things.
* If root calls chroot and changes uid, he expects that the process
can not escape to the old
Hi,
Have you ever wondered why normal users are not allowed to chroot?
I have. The reasons I can figure out are:
* Changing root makes it trivial to trick suid/sgid binaries to do
nasty things.
* If root calls chroot and changes uid, he expects that the process
can not escape to the old
Followup to: 20010627014534.B2654@ondska
By author:Jorgen Cederlof [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
Have you ever wondered why normal users are not allowed to chroot?
I have. The reasons I can figure out are:
* Changing root makes it trivial to trick suid/sgid
In article [EMAIL PROTECTED],
you write:
Safe, perhaps, but also completely useless: there is no way the user
can set up a functional environment inside the chroot. In other
words, it's all pain, no gain.
It could potentially be useful for a network daemon (e.g. a simplified
anonymous FTP
Followup to: [EMAIL PROTECTED]
By author:Paul Menage [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
It could potentially be useful for a network daemon (e.g. a simplified
anonymous FTP server) that wanted to be absolutely sure that neither it
nor any of its libraries were being
H. Peter Anvin wrote:
By author:Jorgen Cederlof [EMAIL PROTECTED]
If we only allow user chroots for processes that have never been
chrooted before, and if the suid/sgid bits won't have any effect under
the new root, it should be perfectly safe to allow any user to chroot.
Safe, perhaps,
Paul Menage wrote:
It could potentially be useful for a network daemon (e.g. a simplified
anonymous FTP server) that wanted to be absolutely sure that neither it
nor any of its libraries were being tricked into following a bogus
symlink, or a /../ in a passed filename. After initialisation, the
It is not rocket science to populate a chroot environment with enough
files to make many interesting applications work. Don't expect a general
solution---chroot is not a silver bullet---but it is useful. (Note also
that whether you can populate a chroot environment sufficiently is roughly
Paul Menage wrote:
This could be regarded as the wrong way to solve such a problem, but
this kind of bug seems to be occurring often enough on BugTraq that it
might be useful if you don't have the resources to do a full security
audit on your program (or if the source to some of your
Paul Menage wrote:
This could be regarded as the wrong way to solve such a problem, but
this kind of bug seems to be occurring often enough on BugTraq that it
might be useful if you don't have the resources to do a full security
audit on your program (or if the source to some of your
On Tue, 26 Jun 2001, Paul Menage wrote:
But only root can set this up, since you currently have to be root in
order to chroot(). The (only) advantage of the user chroot() patch would
be that users would be able to do the same thing without root
intervention.
You need to be root to do
You need to be root to do mknod. You need to do mknod to create /dev/zero.
You need /dev/zero to get anywhere near the normal behaviour of the system.
Sure, but we're not necessarily looking for a system that behaves
normally in all aspects. The example given was that of a paranoid
network
H. Peter Anvin writes:
[somebody]
Have you ever wondered why normal users are not allowed to chroot?
I have. The reasons I can figure out are:
* Changing root makes it trivial to trick suid/sgid binaries to do
nasty things.
* If root calls chroot and changes uid, he expects that the
Albert D. Cahalan wrote:
Normal users can use an environment provided for them.
While trying to figure out why the heyu program would not
work on a Red Hat box, I did just this. As root I set up all
the device files needed, along Debian libraries and the heyu
executable itself. It was
Mohammad A. Haque wrote:
Why do this in the kernel when it's available in userspace?
Because the userspace implementations aren't equivalent.
In particular, it is not so easy for them to enforce the following
restriction:
(*) If a non-root user requested the chroot, then setuid/setgid
63 matches
Mail list logo
