Re: Security by hiding processes

From: Skip Carter (skip@taygeta.com)
Date: 07/23/02


To: remco@rc6.org (Remco B. Brink)
Date: Tue, 23 Jul 2002 10:11:32 -0700
From: Skip Carter <skip@taygeta.com>


Hello,

> Suggestions like restricting access to /proc were named, but there
> were few suggestions on how to properly implement this.
>
> Personally I'm a bit sceptic towards this kind of security through
> obscurity, but I am hoping some of the readers of this list might have
> some input on this.
>
> Does hiding process give a false sense of security? Is it worth the
> effort? What problems can one run into by for example restricting
> access to /proc? Are there better ways to hide process information
> from users?
>
> Any input is well appreciated.

I have some experience with having /proc hidden through the use of chrooted
login environments.
Hiding /proc is trivial in a chroot environment, just do nothing when you
create the environment
-- you have to take some extra effort to make it available (by mounting it in
the chroot).

The problem with this is that some applications need to see what is in /proc
in order to work
properly. This may or not be a problem, depending upon what you are trying to
accomplish
in your chroot space and what you want to allow to run there. Obvious
applications are
'ps' and related programs, but other applications use /proc as well (I
discovered that
Cocoon2 does this, so a chrooted web server that uses Cocoon2 needs to mount
/proc).

In my opinion, the bottom line is that its not too hard to set up an
environment that cannot
see /proc, but its not always practical and shouldn't be relied upon in order
to
maintain security.

Skip

-- 
 Dr. Everett (Skip) Carter      Phone: 831-641-0645 FAX:  831-641-0647
 Taygeta Scientific Inc.        INTERNET: skip@taygeta.com
 1340 Munras Ave., Suite 314    WWW: http://www.taygeta.com
 Monterey, CA. 93940            



Relevant Pages

  • Re: [PATCH 12/18] shared mount handling: bind and rbind
    ... system I could chroot into, and one of the things in the new chroot ... environment was a different boot loader. ... chroot had acquired some unwanted security feature that prevented lilo from ...
    (Linux-Kernel)
  • Its not personal (Was: Re: APACHE$PRIVILEDGED)
    ... As it is a very useful example of UWSS ... Some background on security and privileged application code... ... With OpenVMS constructs including device drivers (or drivers an ... environment -- most anything. ...
    (comp.os.vms)
  • Re: APACHE$PRIVILEDGED
    ... The primary security on OpenVMS and on most other multi-processing operating systems is implemented via the memory management system and via what VAX calls the change-mode routines, via the Alpha SRM PALcode change-mode equivalent, or via what the IA-32 and IA-32e architectures refer to as the call gate. ... With OpenVMS constructs including device drivers )and user-written system services (UWSS; also known as privileged shareable images), these constructs operate in inner processor modes. ... One of the more hazardous situations for system security is a mixed environment; where there are resources shared between trusted and untrusted environments. ... Not only will the operation that requires privileges now be permitted, but other and potentially unintended operations can also be permitted. ...
    (comp.os.vms)
  • RE: IDSIPS that can handle one Gig
    ... the need for IPS ... I hear this every now and then from security people, ... I have yet to see an environment (and I am a consultant so I see ... single Microsoft Windows patch. ...
    (Focus-IDS)
  • RE: Port to z/OS or OMVS?
    ... I must disagree that the z/OS UNIX environment only offers a subset. ... > park when it comes to security. ...
    (bit.listserv.ibm-main)