public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Albert Cahalan <albert@users.sf.net>
To: Bodo Eggert <7eggert@gmx.de>
Cc: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>,
	linux-kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH][RFC] Make /proc/<pid> chmod'able
Date: Tue, 15 Mar 2005 10:58:06 -0500	[thread overview]
Message-ID: <1110902286.7893.237.camel@cube> (raw)
In-Reply-To: <Pine.LNX.4.58.0503151446140.2662@be1.lrz>

On Tue, 2005-03-15 at 15:31 +0100, Bodo Eggert wrote:
> (snipped the CC list - hope that's ok)
> 
> On Mon, 14 Mar 2005, Albert Cahalan wrote:
> > On Tue, 2005-03-15 at 00:08 +0100, Bodo Eggert wrote:
> > > On Mon, 14 Mar 2005, Albert Cahalan wrote:

> > This really isn't about security.
> 
> Information leakage is a security aspect.

If you will go to such extremes, Linux is poorly suited.
A user can detect activity on the computer by examining
the performance of their own activity.

> > Privacy may be undesirable.
> 
> May. That's why I suggested the min/max sysctl.
> 
> > With privacy comes anti-social behavior.
> 
> With anti-social behavior comes the admin and his LART.
> 
> BTW: If the users want to be anti-social, they'll just rename setiathome 
> to something like -bash or soffice.

This does not matter: "Rene, your soffice program is eating
too much CPU time. Find some other place to run it."

> > Supposing that the
> > users do get privacy, perhaps because the have paid for it:
> 
> Vservers,
> > Xen, UML, VM, VMware, separate computers
> > 
> > Going with separate computers is best.
> 
> If you like wasting space and energy. If the user's demands don't exceed 
> one percent of a historic PC, there is no point in buying more hardware.

Sure there is:

a. info leakage (way more than just /proc)
b. admin control
c. budget control
d. downtime hits fewer users

> > Don't forget to use
> > network traffic control to keep users from being able to
> > detect the network activity of other users.
> 
> Like that:?
> 
> $ netstat
> Active Internet connections (w/o servers)
> Proto Recv-Q Send-Q Local Address           Foreign Address         State
> /proc/net/tcp: Permission denied

Nope. If you really care about information leakage, you'll
be concerned about the ability to detect network congestion.

Example #1

A spy sends packets from time to time. He measures the delay
and packet loss to determine if the network is busy. When the
network suddenly becomes busy, he can guess that you have
started some operation that requires heavy network traffic.

Example #2

A spy sends packets from time to time. He measures the delay
and packet loss to determine if the network is busy. Over time,
he learns when workers are busy. From this he can determine an
appropriate time to sneak into your building.

Hey, if you're going to be paranoid about %CPU and %MEM, you
have to be paranoid about %NET too. This requires traffic
control unless you have separate networks. Assign a fixed
portion of bandwidth to any user that you wish to hide info
from. Be sure to consider latency as well.

> > > > Users who want privacy can get their
> > > > own computer. So, these need to work:
> > > > 
> > > > ps [...]
> > > > w
> > > > top
> > > 
> > > Works as intended. Only pstree breaks, if init isn't visible.
> > 
> > They work like they do with a rootkit installed.
> > Traditional behavior has been broken.
> 
> They are as broken as finger or ls are if the home directory is chmodded.

Probably something should be done to deal with the problem of
a chmodded home directory. It's not ls that matters though.
It's du that matters. On a normal shared system, a user should
be able to see where all the disk blocks and inodes are going.
Filenames need not be visible. Then: "Rene, you're being kind
of greedy about the disk space aren't you? You're using 666 GB."



  parent reply	other threads:[~2005-03-15 16:12 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-14  3:34 [PATCH][RFC] Make /proc/<pid> chmod'able Albert Cahalan
2005-03-14  9:42 ` Rene Scharfe
2005-03-14 16:13   ` Albert Cahalan
2005-03-14 23:08     ` Bodo Eggert
2005-03-15  2:44       ` Albert Cahalan
2005-03-15 10:51         ` Jonathan Sambrook
2005-03-15 14:31         ` Bodo Eggert
2005-03-15 15:29           ` Paul Jackson
2005-03-15 15:58           ` Albert Cahalan [this message]
2005-03-15 21:06             ` Bodo Eggert
2005-03-15 21:18         ` Rene Scharfe
2005-03-16  0:21           ` Kyle Moffett
2005-03-15 15:27     ` Rene Scharfe
2005-03-14 16:37   ` Pavel Machek
2005-03-16  2:39 ` [PATCH][RFC] /proc umask and gid [was: Make /proc/<pid> chmod'able] Rene Scharfe
2005-03-16  4:31   ` Albert Cahalan
2005-03-16  4:41   ` Albert Cahalan
2005-03-19  1:51     ` Rene Scharfe
  -- strict thread matches above, loose matches on Subject: below --
2005-03-13 23:32 [PATCH][RFC] Make /proc/<pid> chmod'able Rene Scharfe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1110902286.7893.237.camel@cube \
    --to=albert@users.sf.net \
    --cc=7eggert@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rene.scharfe@lsrfire.ath.cx \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox