/prod/PID-related proc fs question

/prod/PID-related proc fs question

[Calin A. Culianu]

I just noticed something today that I found odd and I know there must be a
good reason for it, but I can't think of what it might be..

Basically if I am listing the contents of a /proc/PID directory, it seems
that the cwd, exe, and root (symlink) entries are invalid unless the
process corresponding to PID is a process owned by me, or I am root.  Why
is this?

Is this feature security related?

If so I can't really think of any security issues that would arise from
having that information as a non-priviledged user.

It would seem reasonable to me that users seeing each other's
/prod/PID/root and /proc/PID/exe symlinks isn't really much of a security
vulnerability.. Plus it would make possible a non-root user to grab
statistics on the most popular running binaries, the number of chrooted
processes.. etc..  probably trivial statistics but it still would be nice
to see if any other instance of an application is running (unless there
already is another mechanism for this that I am unaware of).

Anyway any answers appreciated...

-Calin

Re: /prod/PID-related proc fs question

[Richard B. Johnson]

On Wed, 6 Nov 2002, Calin A. Culianu wrote:

> 
> I just noticed something today that I found odd and I know there must be a
> good reason for it, but I can't think of what it might be..
> 
> Basically if I am listing the contents of a /proc/PID directory, it seems
> that the cwd, exe, and root (symlink) entries are invalid unless the
> process corresponding to PID is a process owned by me, or I am root.  Why
> is this?
> 
> Is this feature security related?
> 
> If so I can't really think of any security issues that would arise from
> having that information as a non-priviledged user.
> 
> It would seem reasonable to me that users seeing each other's
> /prod/PID/root and /proc/PID/exe symlinks isn't really much of a security
> vulnerability.. Plus it would make possible a non-root user to grab
> statistics on the most popular running binaries, the number of chrooted
> processes.. etc..  probably trivial statistics but it still would be nice
> to see if any other instance of an application is running (unless there
> already is another mechanism for this that I am unaware of).
> 
> Anyway any answers appreciated...
> 
> -Calin



Well you know that you can send a "secret" message
from one task to another using Morse code?

As a trivial example, I could use a lot of CPU time
for a second:
     while(time(NULL) == saved)
            ;

I could call this a "dash".

Then I could use a tiny bit and call it a "dot":
    sleep(1);

I could then use a little bit and call it a space:
    while(time(NULL) == saved)
        usleep(1);

If another task knew this, and could have access to my
task's CPU time statistics, I could send messages through
an "undocumented" or "rogue" channel.

This may seem dumb, and the example is, however there
are commercial systems out there where you don't want any
undocumented communications paths between tasks. They
might be performing stock transactions for competing
clients, etc. A back-door communications path could
be used to steal. So, it might not be a good idea to give
away information that another task doesn't have a "need-to-know".



Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
   Bush : The Fourth Reich of America

Re: /prod/PID-related proc fs question

[Calin A. Culianu]

On Wed, 6 Nov 2002, Richard B. Johnson wrote:

> On Wed, 6 Nov 2002, Calin A. Culianu wrote:
>
> >
> > I just noticed something today that I found odd and I know there must be a
> > good reason for it, but I can't think of what it might be..
> >
> > Basically if I am listing the contents of a /proc/PID directory, it seems
> > that the cwd, exe, and root (symlink) entries are invalid unless the
> > process corresponding to PID is a process owned by me, or I am root.  Why
> > is this?
> >
> > Is this feature security related?
> >
> > If so I can't really think of any security issues that would arise from
> > having that information as a non-priviledged user.
> >
> > It would seem reasonable to me that users seeing each other's
> > /prod/PID/root and /proc/PID/exe symlinks isn't really much of a security
> > vulnerability.. Plus it would make possible a non-root user to grab
> > statistics on the most popular running binaries, the number of chrooted
> > processes.. etc..  probably trivial statistics but it still would be nice
> > to see if any other instance of an application is running (unless there
> > already is another mechanism for this that I am unaware of).
> >
> > Anyway any answers appreciated...
> >
> > -Calin
>
>
>
> Well you know that you can send a "secret" message
> from one task to another using Morse code?
>
> As a trivial example, I could use a lot of CPU time
> for a second:
>      while(time(NULL) == saved)
>             ;
>
> I could call this a "dash".
>
> Then I could use a tiny bit and call it a "dot":
>     sleep(1);
>
> I could then use a little bit and call it a space:
>     while(time(NULL) == saved)
>         usleep(1);
>
> If another task knew this, and could have access to my
> task's CPU time statistics, I could send messages through
> an "undocumented" or "rogue" channel.
>
> This may seem dumb, and the example is, however there
> are commercial systems out there where you don't want any
> undocumented communications paths between tasks. They
> might be performing stock transactions for competing
> clients, etc. A back-door communications path could
> be used to steal. So, it might not be a good idea to give
> away information that another task doesn't have a "need-to-know".
>

Well then in this case why not block out /proc/PID/maps then?  In general
the first entry of this file _IS_ /proc/PID/exe!!

Also, in such systems there exist modification to the proc fs so that
processes can't see any other users, and so that proc fs is VERY empty
and provides minimal information.


This still isn't a good reason for not allowing people to see
/prod/PID/exe.. anyone else have an idea as to why this policy exists in
the kernel?

-Calin

Re: /prod/PID-related proc fs question

[Calin A. Culianu]

On Wed, 6 Nov 2002, Calin A. Culianu wrote:

> On Wed, 6 Nov 2002, Richard B. Johnson wrote:
>
> > On Wed, 6 Nov 2002, Calin A. Culianu wrote:
> >
> > >
> > > I just noticed something today that I found odd and I know there must be a
> > > good reason for it, but I can't think of what it might be..
> > >
> > > Basically if I am listing the contents of a /proc/PID directory, it seems
> > > that the cwd, exe, and root (symlink) entries are invalid unless the
> > > process corresponding to PID is a process owned by me, or I am root.  Why
> > > is this?
> > >
> > > Is this feature security related?
> > >
> > > If so I can't really think of any security issues that would arise from
> > > having that information as a non-priviledged user.
> > >
> > > It would seem reasonable to me that users seeing each other's
> > > /prod/PID/root and /proc/PID/exe symlinks isn't really much of a security
> > > vulnerability.. Plus it would make possible a non-root user to grab
> > > statistics on the most popular running binaries, the number of chrooted
> > > processes.. etc..  probably trivial statistics but it still would be nice
> > > to see if any other instance of an application is running (unless there
> > > already is another mechanism for this that I am unaware of).
> > >
> > > Anyway any answers appreciated...
> > >
> > > -Calin
> >
> >
> >
> > Well you know that you can send a "secret" message
> > from one task to another using Morse code?
> >
> > As a trivial example, I could use a lot of CPU time
> > for a second:
> >      while(time(NULL) == saved)
> >             ;
> >
> > I could call this a "dash".
> >
> > Then I could use a tiny bit and call it a "dot":
> >     sleep(1);
> >
> > I could then use a little bit and call it a space:
> >     while(time(NULL) == saved)
> >         usleep(1);
> >
> > If another task knew this, and could have access to my
> > task's CPU time statistics, I could send messages through
> > an "undocumented" or "rogue" channel.

Also, this is still possible even without a proc fs.  You can do this as
you mentioned but instead of looking in /proc for cpu time stats you can
just keep issuing sleep() then gettimeofday() syscalls... and the jitter
with respect to how long it takes you to wake up each sleep cycle could
possibly be your 'morse code' dot-dash scheme.

It is still going to be a _very_ noisy communication channel, and probably
requries some adaptive algorithm that can negotiate the meaning of
a 'dot' and 'dash' in a system-specific way.. (and can re-negotiate
it to cope with unforseen load on the system)...


-Calin

Re: /prod/PID-related proc fs question

[Frank v Waveren]

How about just modifiying argv? or forking? or using diskspace/statfs?
Basicly, you can't stop covert communication between processes unless
you use a _very_ heavily patched kernel, and this was never a design
goal.

-- 
Frank v Waveren                                      Fingerprint: 21A7 C7F3
fvw@[var.cx|stack.nl|dse.nl|chello.nl] ICQ#10074100     1FF3 47FF 545C CB53
Public key: hkp://wwwkeys.pgp.net/fvw@var.cx            7BD9 09C0 3AC1 6DF2