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.
> >
> >
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 c
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
[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
> 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
s
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 exi
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
> > chroote
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 configur
[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
[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
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 ge
[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
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 perfec
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 shou
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,
[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 u
[EMAIL PROTECTED] (Paul Menage) wrote on 26.06.01 in
<[EMAIL PROTECTED]>:
> >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 tha
[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 ch
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
bi
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 ex
>
>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
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 m
>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 libra
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
indepe
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,
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 being
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 F
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/sg
33 matches
Mail list logo
