On Fri, 14 Sep 2007, Andreas Schwab wrote:
> Bodo Eggert <[EMAIL PROTECTED]> writes:
> > ~/tmp > cp /bin/sleep .
> > ~/tmp > chmod u+s sleep
> > ~/tmp > ./sleep 2147483647 &
> > [1] 2823
> > ~/tmp > strace -p 2823
> > Process 2823 attached - interrupt to quit
> > setup(
>
> You didn't change the
Brent Casavant <[EMAIL PROTECTED]> writes:
> My (limited) understanding of ptrace is that a parent-child
> relationship is needed between the tracing process and the traced
> process (at least that's what I gather from the man page). This
> does give cause for concern, and I might have to see
Bodo Eggert <[EMAIL PROTECTED]> writes:
> ~/tmp > cp /bin/sleep .
> ~/tmp > chmod u+s sleep
> ~/tmp > ./sleep 2147483647 &
> [1] 2823
> ~/tmp > strace -p 2823
> Process 2823 attached - interrupt to quit
> setup(
You didn't change the owner, so this is not a setuid execution.
Andreas.
--
Brent Casavant <[EMAIL PROTECTED]> wrote:
[...]
> Hmm. This will work as long as the peer process is running setuid
> to it's own unique user. Excellent idea! Since I need to make the
> program setuid to avoid non-priveleged ptrace attacks, this is a
> terrific solution.
Tried that:
~ > cd
On Thu, 13 Sep 2007, Jan Kara wrote:
> > > However, it occurs to me that this problem goes away if there were
> > > a method create a file in an unlinked state to begin with. However
> > > there does not appear to be any such mechanism in Linux's open()
> > > interface.
> >
> > Having no window
On Thu, 13 Sep 2007, Jan Kara wrote:
However, it occurs to me that this problem goes away if there were
a method create a file in an unlinked state to begin with. However
there does not appear to be any such mechanism in Linux's open()
interface.
Having no window for creating
Brent Casavant [EMAIL PROTECTED] wrote:
[...]
Hmm. This will work as long as the peer process is running setuid
to it's own unique user. Excellent idea! Since I need to make the
program setuid to avoid non-priveleged ptrace attacks, this is a
terrific solution.
Tried that:
~ cd tmp
Bodo Eggert [EMAIL PROTECTED] writes:
~/tmp cp /bin/sleep .
~/tmp chmod u+s sleep
~/tmp ./sleep 2147483647
[1] 2823
~/tmp strace -p 2823
Process 2823 attached - interrupt to quit
setup(
You didn't change the owner, so this is not a setuid execution.
Andreas.
--
Andreas Schwab,
Brent Casavant [EMAIL PROTECTED] writes:
My (limited) understanding of ptrace is that a parent-child
relationship is needed between the tracing process and the traced
process (at least that's what I gather from the man page). This
does give cause for concern, and I might have to see what can
On Fri, 14 Sep 2007, Andreas Schwab wrote:
Bodo Eggert [EMAIL PROTECTED] writes:
~/tmp cp /bin/sleep .
~/tmp chmod u+s sleep
~/tmp ./sleep 2147483647
[1] 2823
~/tmp strace -p 2823
Process 2823 attached - interrupt to quit
setup(
You didn't change the owner, so this is not a
On Thu, 13 Sep 2007, Gabor Gombas wrote:
> On Wed, Sep 12, 2007 at 03:37:44PM -0500, Brent Casavant wrote:
>
> > System V shmem is right out because the IPC key is publicly
> > visible and there is no combination of permissions which
> > will allow sharing the segment with just one other process
On Wed, Sep 12, 2007 at 03:37:44PM -0500, Brent Casavant wrote:
> System V shmem is right out because the IPC key is publicly
> visible and there is no combination of permissions which
> will allow sharing the segment with just one other process
> (or at least just one other user). To my
> > However, it occurs to me that this problem goes away if there were
> > a method create a file in an unlinked state to begin with. However
> > there does not appear to be any such mechanism in Linux's open()
> > interface.
>
> Having no window for creating stale temp files is nice to have. We
However, it occurs to me that this problem goes away if there were
a method create a file in an unlinked state to begin with. However
there does not appear to be any such mechanism in Linux's open()
interface.
Having no window for creating stale temp files is nice to have. We only
On Wed, Sep 12, 2007 at 03:37:44PM -0500, Brent Casavant wrote:
System V shmem is right out because the IPC key is publicly
visible and there is no combination of permissions which
will allow sharing the segment with just one other process
(or at least just one other user). To my knowledge
On Thu, 13 Sep 2007, Gabor Gombas wrote:
On Wed, Sep 12, 2007 at 03:37:44PM -0500, Brent Casavant wrote:
System V shmem is right out because the IPC key is publicly
visible and there is no combination of permissions which
will allow sharing the segment with just one other process
(or
On Wed, 12 Sep 2007, Brent Casavant wrote:
> On Wed, 12 Sep 2007, Al Viro wrote:
>
> > Give me a break. And learn about ptrace(2). This "unlinking" bullshit
> > buys you zero additional security, both for /proc/*/mem and for /dev/mem
> > (see mknod(2)).
>
> My (limited) understanding of
On Wed, 12 Sep 2007, Al Viro wrote:
> On Wed, Sep 12, 2007 at 05:44:30PM -0500, Brent Casavant wrote:
>
> > P.S. By the way, there doesn't seem to be a way to remove /proc/#/mem
> > files. That might be an additional nicety -- programs worried about
> > being snooped could unlink
On Wed, Sep 12, 2007 at 05:44:30PM -0500, Brent Casavant wrote:
> P.S. By the way, there doesn't seem to be a way to remove /proc/#/mem
> files. That might be an additional nicety -- programs worried about
> being snooped could unlink their own entry. /dev/mem and /dev/kmem
> can
aving the daemon half
of the design create these files, however it would provide a bit more
flexibility if the client side was also capable of creating them. It's
not a make-or-break problem, by any means, but does somewhat motivate
an O_NOLINK flag for open().
Brent
P.S. By the way, there doe
Brent Casavant <[EMAIL PROTECTED]> wrote:
[...]
> I could mmap a temporary tmpfs file (tmpfs so that if there is a
> machine crash no sensitive data persists) which is created with
> permissions of 0, immediately unlink it, and pass the file
> descriptor through an AF_UNIX socket. This does open
Brent Casavant <[EMAIL PROTECTED]> writes:
> I could mmap a temporary tmpfs file (tmpfs so that if there is a
> machine crash no sensitive data persists) which is created with
> permissions of 0, immediately unlink it, and pass the file
> descriptor through an AF_UNIX socket. This does open up a
Brent Casavant wrote:
> On Wed, 12 Sep 2007, H. Peter Anvin wrote:
>
>> Brent Casavant wrote:
>
>>> http://marc.info/?l=linux-kernel=93032806224160=2
>> This link talks about file flags handling. I don't see the relevance to
>> this problem at all. However, this is a very long thread, so
On Wed, 12 Sep 2007, H. Peter Anvin wrote:
> Brent Casavant wrote:
> > http://marc.info/?l=linux-kernel=93032806224160=2
>
> This link talks about file flags handling. I don't see the relevance to
> this problem at all. However, this is a very long thread, so if there
> is anything
Brent Casavant wrote:
>
> I could mmap a temporary tmpfs file (tmpfs so that if there is a
> machine crash no sensitive data persists) which is created with
> permissions of 0, immediately unlink it, and pass the file
> descriptor through an AF_UNIX socket. This does open up a very
> small
that if root or the
daemon's user are malicious, all bets are off anyway.
Fully understanding this, it was suggested to me that I could fire
this problem off to lkml to see if anyone has a solution I haven't
already dismissed, or as a trial balloon for considering adding
O_NOLINK to open().
Thoughts
that if root or the
daemon's user are malicious, all bets are off anyway.
Fully understanding this, it was suggested to me that I could fire
this problem off to lkml to see if anyone has a solution I haven't
already dismissed, or as a trial balloon for considering adding
O_NOLINK to open().
Thoughts
Brent Casavant wrote:
I could mmap a temporary tmpfs file (tmpfs so that if there is a
machine crash no sensitive data persists) which is created with
permissions of 0, immediately unlink it, and pass the file
descriptor through an AF_UNIX socket. This does open up a very
small window of
On Wed, 12 Sep 2007, H. Peter Anvin wrote:
Brent Casavant wrote:
http://marc.info/?l=linux-kernelm=93032806224160w=2
This link talks about file flags handling. I don't see the relevance to
this problem at all. However, this is a very long thread, so if there
is anything specific
Brent Casavant wrote:
On Wed, 12 Sep 2007, H. Peter Anvin wrote:
Brent Casavant wrote:
http://marc.info/?l=linux-kernelm=93032806224160w=2
This link talks about file flags handling. I don't see the relevance to
this problem at all. However, this is a very long thread, so if there
Brent Casavant [EMAIL PROTECTED] writes:
I could mmap a temporary tmpfs file (tmpfs so that if there is a
machine crash no sensitive data persists) which is created with
permissions of 0, immediately unlink it, and pass the file
descriptor through an AF_UNIX socket. This does open up a very
Brent Casavant [EMAIL PROTECTED] wrote:
[...]
I could mmap a temporary tmpfs file (tmpfs so that if there is a
machine crash no sensitive data persists) which is created with
permissions of 0, immediately unlink it, and pass the file
descriptor through an AF_UNIX socket. This does open up a
On Wed, Sep 12, 2007 at 05:44:30PM -0500, Brent Casavant wrote:
P.S. By the way, there doesn't seem to be a way to remove /proc/#/mem
files. That might be an additional nicety -- programs worried about
being snooped could unlink their own entry. /dev/mem and /dev/kmem
can
provide a bit more
flexibility if the client side was also capable of creating them. It's
not a make-or-break problem, by any means, but does somewhat motivate
an O_NOLINK flag for open().
Brent
P.S. By the way, there doesn't seem to be a way to remove /proc/#/mem
files. That might
On Wed, 12 Sep 2007, Al Viro wrote:
On Wed, Sep 12, 2007 at 05:44:30PM -0500, Brent Casavant wrote:
P.S. By the way, there doesn't seem to be a way to remove /proc/#/mem
files. That might be an additional nicety -- programs worried about
being snooped could unlink their own
On Wed, 12 Sep 2007, Brent Casavant wrote:
On Wed, 12 Sep 2007, Al Viro wrote:
Give me a break. And learn about ptrace(2). This unlinking bullshit
buys you zero additional security, both for /proc/*/mem and for /dev/mem
(see mknod(2)).
My (limited) understanding of ptrace is that a
36 matches
Mail list logo
