Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-15 Thread Jonathan Sambrook
Xen, UML, VM, VMware, separate computers
http://linux-vserver.org/ would also seem to be an excellent match.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-15 Thread Bodo Eggert
(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:
   On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
Albert Cahalan wrote:

  NACK, the admin (and with the new inherited capabilities all users with 
  cap_???_override) can see all processes. Only users who don't need to know
  won't see the other user's processes.
 
 Capabilities are too broken for most people to use.

That's being fixed, the new semantics will allow a wrapper.

   Note that the admin hopefully does not normally run as root.
  
  su1 and sudo exist.
 
 This is a pain.

mv ps ps.bin # -+ or just ln -s /usr/bin/us1 ~admin/bin/ps instead
ln -s su1 ps # /
echo $'\nask never\nalias ps /bin/ps\nallow admin prefix ps'  /etc/su1.priv
# ore use * instead of admin, if all users are supposed to see everyone.

Or use the sysctl I described. It won't hurt more than the originally 
suggested flag, and it's much more powerfull.

 Now every user will need sudo access,
 and the sudoers file will have to disable requesting
 passwords so that scripts will work without hassle.

Is sudo _that_ bad? Seems it was a good decision to avoid sudo.

   Even if the admin were not running as a normal user, it is
   expected that normal users can keep tabs on each other.
   The admin may be sleeping. Social pressure is important to
   prevent one user from sucking up all the memory and CPU time.
  
  Privacy is important, too. Imagine each user can see the CEO (or the
  admin) executing ee nakedgirl.jpg.
 
 Obviously, he likes to have users see him do this.
 He'd use a private machine if he wanted privacy.

UNIX and linux are supposed to be a multi-user-systems unlike Win98.
Information leakage is usurally considered {\HUGE BAD}, and some security 
models demand closing all information leakages from privileged users to 
less privileged users. Restricted proc is one more step towards secure 
systems, unless you're depending on peer review.

 Note: I'm the procps (ps, top, w, etc.) maintainer.
 
 Probably I'd have to make /bin/ps run setuid root
 to deal with this. (minor changes needed) The same
 goes for /usr/bin/top, which I know is currently
 unsafe and difficult to fix.
  
  I used unpatched procps 3.1.11, and it worked for me, except pstree.
 
 It does not work correctly.
 
 Look, patches with this feature are called rootkits.
 Think of the headlines: Linux now with built-in rootkit.

Using another PC will hide the processes. Therefore using another PC is 
like using a rootkit. NOT.

Maybe you'll want to print a note about inaccessible proc entries, but 
that's a different issue.

Why do ps and top need to be setuid root to deal with a resticted 
/proc? 
What information in /proc/pid needs to be available to any and 
all 
users?
   
   Anything provided by traditional UNIX and BSD systems
   should be available.
  
  e.g. the buffer overflow in sendmail? Or all the open relays? :)
  
  The demands to security and privacy have increased. Linux should be able 
  to provide the requested privacy.
 
 This really isn't about security.

Information leakage is a security aspect.

 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.

 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.

 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

   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.
-- 
Top 100 things you don't want the sysadmin to say:
13. Ooohh, lovely, it runs SVR4
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-15 Thread Rene Scharfe
Albert Cahalan wrote:
Note that the admin hopefully does not normally run as root.
The admin should be using a normal user account most of the
time, to reduce the damage caused by his accidents.
Openwall and GrSecurity solved this by having a special group that can 
see everything, just like root.  E.g. we could add a proc.gid kernel 
boot option for that purpose.

Even if the admin were not running as a normal user, it is
expected that normal users can keep tabs on each other.
The admin may be sleeping. Social pressure is important to
prevent one user from sucking up all the memory and CPU time.
IANAL, but creating a user profile (who ran what when, used how many 
resources etc.) without the user's consent is illegal at least here in 
Germany.  As an admin I'd like to be able to prevent a user from even 
trying to spy on another user.

Anything provided by traditional UNIX and BSD systems
should be available. Users who want privacy can get their
own computer. So, these need to work:
ps -ef
ps -el
ps -ej
ps axu
ps axl
ps axj
ps axv
w
top
If with work you mean show info about all users then the patch 
becomes pointless.  The programs work in the sense that they do *not* 
should cloaked processes, which is intended. :)

OK, I understand that you need to be able to turn this feature off and I 
also don't want non-root admins to suddenly go blind.  Would adding a 
proc.gid kernel parameter and an off-switch be sufficient for you?

Thanks,
Rene
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-15 Thread Paul Jackson
 (snipped the CC list - hope that's ok)

No - it's not ok.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-15 Thread Albert Cahalan
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.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-15 Thread Bodo Eggert
(refiled the CC list)

On Tue, 15 Mar 2005, Albert Cahalan wrote:
 On Tue, 2005-03-15 at 15:31 +0100, Bodo Eggert wrote:
  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.

Way to go, better start walking.

   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.

That's ok for _some_ environments.

   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)

selinux, rsbac,.

 b. admin control
 c. budget control
 d. downtime hits fewer users

no central administration, higher expenses.

The battle has ben fought since the early days, and there is still no 
winner.

   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.

Those who should be are able to see the network usage.

On the other hand, the privileged user might open and close ports to 
signal information to less privileged users.

[examples]

 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.

Traffic shaping is available.

 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.

That's what quota is for.
-- 
If at first you don't succeed call in an air-strike. 

Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
 [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-15 Thread Rene Scharfe
Albert Cahalan wrote:
This really isn't about security. Privacy may be undesirable.
I agree, privacy is not security.  My patch tries to enhance privacy 
without giving up security.

You think losing the social pressure that comes with mutual surveillance 
results in loss of security, I don't.  Now I think Linux should support 
both ways and those writing security policies should make the decision.

With privacy comes anti-social behavior. Supposing that the
users do get privacy, perhaps because the have paid for it:
Xen, UML, VM, VMware, separate computers
Going with separate computers is best. Don't forget to use
network traffic control to keep users from being able to
detect the network activity of other users.
That would work, but it requires a *lot* of administrative and computing 
overhead.  Note that separate computers alone is not sufficient 
because most places with more than a few machines have some kind of 
single signon and run SSH or similar.

[ps, w, top]
They work like they do with a rootkit installed.
Traditional behavior has been broken.
That's one way to put it; you could also say those tools now provide 
enhanced privacy. ;)

I also think things have changed in the last few years.  Since the 
advent of special data processing laws privacy is taken more serious. 
Privacy certainly was no real concern when UNIX was young.  I also guess 
it's a cultural thing, its importance being different from country to 
country.

It's easily visible in the style of public toilets: in some contries you 
have one big room with no walls in between where all men or women 
merrily shit together, in other countries (like mine) every person can 
lock himself into a private closet.  Both ways work, there's nothing too 
special about using a toilet, but I'm simply used to the privacy 
provided by those thin walls.  I assure you, I don't do anything evil in 
there. :]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-15 Thread Kyle Moffett
On Mar 15, 2005, at 16:18, Rene Scharfe wrote:
It's easily visible in the style of public toilets: in some contries 
you have one big room with no walls in between where all men or women 
merrily shit together, in other countries (like mine) every person can 
lock himself into a private closet.  Both ways work, there's nothing 
too special about using a toilet, but I'm simply used to the privacy 
provided by those thin walls.  I assure you, I don't do anything evil 
in there. :]
Just as long as our labs bathrooms don't mysteriously get a
bazillion walls all over the place on kernel upgrade, we're ok.
I don't mind adding new options for advanced security, as long
as you don't change the defaults.  It's hard enough managing
a boatload of workstations under ideal conditions.  When the
default settings change every month it gets really annoying
really quickly. :-D.
Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C$ UB/L/X/*(+)$ P+++()$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e-$ h!*()++$ r  
!y?(-)
--END GEEK CODE BLOCK--

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-14 Thread Rene Scharfe
Albert Cahalan wrote:
This is a bad idea. Users should not be allowed to
make this decision. This is rightly a decision for
the admin to make.
Why do you think users should not be allowed to chmod their processes' 
/proc directories?  Isn't it similar to being able to chmod their home 
directories?  They own both objects, after all (both conceptually and as 
attributed in the filesystem).

Note: I'm the procps (ps, top, w, etc.) maintainer.
Probably I'd have to make /bin/ps run setuid root
to deal with this. (minor changes needed) The same
goes for /usr/bin/top, which I know is currently
unsafe and difficult to fix.
Let's not go there, OK?
I have to admit to not having done any real testing with those 
utilities.  My excuse is this isn't such a new feature, Openwall had 
something similar for at least four years now and GrSecurity contains 
yet another flavour of it.  Openwall also provides one patch for 
procps-2.0.6, so I figured that problem (whatever their patch is about) 
got fixed in later versions.

Why do ps and top need to be setuid root to deal with a resticted /proc? 
   What information in /proc/pid needs to be available to any and all 
users?

If you restricted this new ability to root, then I'd
have much less of an objection. (not that I'd like it)
How about a boot parameter or sysctl to enable the chmod'ability of 
/proc/pid, defaulting to off?  But I'd like to resolve your more 
general objections above first, if possible. :)

Thanks for your comments,
Rene
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-14 Thread Albert Cahalan
On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
 Albert Cahalan wrote:
  This is a bad idea. Users should not be allowed to
  make this decision. This is rightly a decision for
  the admin to make.
 
 Why do you think users should not be allowed to chmod their processes' 
 /proc directories?  Isn't it similar to being able to chmod their home 
 directories?  They own both objects, after all (both conceptually and as 
 attributed in the filesystem).

This is, to use your own word, cloaking. This would let
a bad user or even an unauthorized user hide from the admin.
Why should someone be able to hide a suspicious CPU hog?
Maybe they are cracking passwords or selling your CPU time.

Note that the admin hopefully does not normally run as root.
The admin should be using a normal user account most of the
time, to reduce the damage caused by his accidents.

Even if the admin were not running as a normal user, it is
expected that normal users can keep tabs on each other.
The admin may be sleeping. Social pressure is important to
prevent one user from sucking up all the memory and CPU time.

  Note: I'm the procps (ps, top, w, etc.) maintainer.
  
  Probably I'd have to make /bin/ps run setuid root
  to deal with this. (minor changes needed) The same
  goes for /usr/bin/top, which I know is currently
  unsafe and difficult to fix.
  
  Let's not go there, OK?
 
 I have to admit to not having done any real testing with those 
 utilities.  My excuse is this isn't such a new feature, Openwall had 
 something similar for at least four years now and GrSecurity contains 
 yet another flavour of it.  Openwall also provides one patch for 
 procps-2.0.6, so I figured that problem (whatever their patch is about) 
 got fixed in later versions.

If I haven't seen that patch, to Hell with 'em.

It appears that Openwall is using procps-2.0.7 now. Oooh, they've
upgraded to something that's only 4.5 years old! Anybody using a
4-year-old procps is uninterested in security.

 Why do ps and top need to be setuid root to deal with a resticted /proc? 
 What information in /proc/pid needs to be available to any and all 
 users?

Anything provided by traditional UNIX and BSD systems
should be available. Users who want privacy can get their
own computer. So, these need to work:

ps -ef
ps -el
ps -ej
ps axu
ps axl
ps axj
ps axv
w
top

Note that /proc does provide a bit more info than required.
This could be changed; it requires new /proc files or a
non-proc source of data.

  If you restricted this new ability to root, then I'd
  have much less of an objection. (not that I'd like it)
 
 How about a boot parameter or sysctl to enable the chmod'ability of 
 /proc/pid, defaulting to off?  But I'd like to resolve your more 
 general objections above first, if possible. :)

This at least avoids breaking the traditional ability of
non-root users to spot abuse.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-14 Thread Pavel Machek
Hi!

 This is a bad idea. Users should not be allowed to
 make this decision. This is rightly a decision for
 the admin to make.
 
 Why do you think users should not be allowed to chmod their processes' 
 /proc directories?  Isn't it similar to being able to chmod their home 
 directories?  They own both objects, after all (both conceptually and as 
 attributed in the filesystem).

As a co-admin of university server...

Yes, I want users to see what each other user is doing. That way, if
someone hacks one account, some other user can notice and tell me.

In some environments it may make sense not to allow users to chmod
their $HOMEs (so that they can't hide mp3's etc), but we are not
*that* stupid/paranoid ;-).
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-14 Thread Bodo Eggert
On Mon, 14 Mar 2005, Albert Cahalan wrote:
 On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
  Albert Cahalan wrote:

  Why do you think users should not be allowed to chmod their processes' 
  /proc directories?  Isn't it similar to being able to chmod their home 
  directories?  They own both objects, after all (both conceptually and as 
  attributed in the filesystem).
 
 This is, to use your own word, cloaking. This would let
 a bad user or even an unauthorized user hide from the admin.

NACK, the admin (and with the new inherited capabilities all users with 
cap_???_override) can see all processes. Only users who don't need to know
won't see the other user's processes.

 Note that the admin hopefully does not normally run as root.

su1 and sudo exist.

 Even if the admin were not running as a normal user, it is
 expected that normal users can keep tabs on each other.
 The admin may be sleeping. Social pressure is important to
 prevent one user from sucking up all the memory and CPU time.

Privacy is important, too. Imagine each user can see the CEO (or the
admin) executing ee nakedgirl.jpg.

   Note: I'm the procps (ps, top, w, etc.) maintainer.
   
   Probably I'd have to make /bin/ps run setuid root
   to deal with this. (minor changes needed) The same
   goes for /usr/bin/top, which I know is currently
   unsafe and difficult to fix.

I used unpatched procps 3.1.11, and it worked for me, except pstree.

  Why do ps and top need to be setuid root to deal with a resticted /proc? 
  What information in /proc/pid needs to be available to any and all 
  users?
 
 Anything provided by traditional UNIX and BSD systems
 should be available.

e.g. the buffer overflow in sendmail? Or all the open relays? :)

The demands to security and privacy have increased. Linux should be able 
to provide the requested privacy.

 Users who want privacy can get their
 own computer. So, these need to work:
 
 ps -ef
 ps -el
 ps -ej
 ps axu
 ps axl
 ps axj
 ps axv
 w
 top

Works as intended. Only pstree breaks, if init isn't visible.

   If you restricted this new ability to root, then I'd
   have much less of an objection. (not that I'd like it)
  
  How about a boot parameter or sysctl to enable the chmod'ability of 
  /proc/pid, defaulting to off?  But I'd like to resolve your more 
  general objections above first, if possible. :)

I'd prefer a minimum and a maximum mask. If the admin wants to enforce 
privacy, he can do it, and if he wants the users to spy on each other, so 
be it.
-- 
Top 100 things you don't want the sysadmin to say:
23. What do mean by fired?

Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-14 Thread Albert Cahalan
On Tue, 2005-03-15 at 00:08 +0100, Bodo Eggert wrote:
 On Mon, 14 Mar 2005, Albert Cahalan wrote:
  On Mon, 2005-03-14 at 10:42 +0100, Rene Scharfe wrote:
   Albert Cahalan wrote:
 
   Why do you think users should not be allowed to chmod their processes' 
   /proc directories?  Isn't it similar to being able to chmod their home 
   directories?  They own both objects, after all (both conceptually and as 
   attributed in the filesystem).
  
  This is, to use your own word, cloaking. This would let
  a bad user or even an unauthorized user hide from the admin.
 
 NACK, the admin (and with the new inherited capabilities all users with 
 cap_???_override) can see all processes. Only users who don't need to know
 won't see the other user's processes.

Capabilities are too broken for most people to use. Normal users
do not get CAP_DAC_OVERRIDE by default anyway, for good reason.

  Note that the admin hopefully does not normally run as root.
 
 su1 and sudo exist.

This is a pain. Now every user will need sudo access,
and the sudoers file will have to disable requesting
passwords so that scripts will work without hassle.

  Even if the admin were not running as a normal user, it is
  expected that normal users can keep tabs on each other.
  The admin may be sleeping. Social pressure is important to
  prevent one user from sucking up all the memory and CPU time.
 
 Privacy is important, too. Imagine each user can see the CEO (or the
 admin) executing ee nakedgirl.jpg.

Obviously, he likes to have users see him do this.
He'd use a private machine if he wanted privacy.

Note: I'm the procps (ps, top, w, etc.) maintainer.

Probably I'd have to make /bin/ps run setuid root
to deal with this. (minor changes needed) The same
goes for /usr/bin/top, which I know is currently
unsafe and difficult to fix.
 
 I used unpatched procps 3.1.11, and it worked for me, except pstree.

It does not work correctly.

Look, patches with this feature are called rootkits.
Think of the headlines: Linux now with built-in rootkit.

   Why do ps and top need to be setuid root to deal with a resticted /proc? 
   What information in /proc/pid needs to be available to any and all 
   users?
  
  Anything provided by traditional UNIX and BSD systems
  should be available.
 
 e.g. the buffer overflow in sendmail? Or all the open relays? :)
 
 The demands to security and privacy have increased. Linux should be able 
 to provide the requested privacy.

This really isn't about security. Privacy may be undesirable.
With privacy comes anti-social behavior. Supposing that the
users do get privacy, perhaps because the have paid for it:

Xen, UML, VM, VMware, separate computers

Going with separate computers is best. Don't forget to use
network traffic control to keep users from being able to
detect the network activity of other users.

  Users who want privacy can get their
  own computer. So, these need to work:
  
  ps -ef
  ps -el
  ps -ej
  ps axu
  ps axl
  ps axj
  ps axv
  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.


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH][RFC] Make /proc/pid chmod'able

2005-03-13 Thread Albert Cahalan
 OK, folks, another try to enhance privacy by hiding
 process details from other users.  Why not simply use
 chmod to set the permissions of /proc/pid directories?
 This patch implements it.

 Children processes inherit their parents' proc
 permissions on fork.  You can only set (and remove)
 read and execute permissions, the bits for write,
 suid etc. are not changable.  A user would add

 chmod 500 /proc/$$

 or something similar to his .profile to cloak his processes.

 What do you think about that one?

This is a bad idea. Users should not be allowed to
make this decision. This is rightly a decision for
the admin to make.

Note: I'm the procps (ps, top, w, etc.) maintainer.

Probably I'd have to make /bin/ps run setuid root
to deal with this. (minor changes needed) The same
goes for /usr/bin/top, which I know is currently
unsafe and difficult to fix.

Let's not go there, OK?

If you restricted this new ability to root, then I'd
have much less of an objection. (not that I'd like it)



-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/