Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 479
  • Last Modified:

FreeBSD 4.x: Safe to unmount the proc filesystem??

guys,
 
This question relates to patching a security hole in FREEBSD 4.1 as advised in the advisory below.

My question is:  
Is it safe to unmount the proc filesystem on a production server ?
Can this be used as a permanent workaround ?
Please advice...
 
Tq!
 
>>>>>>>>
 
FreeBSD-SA-01:55
procfs vulnerability leaks set[ug]id process memory

IV. Workaround

To work around the problem, perform the following steps as root:

Unmount all instances of the procfs and linprocfs filesystems using
the unmount(8) command:

# umount -f -a -t procfs
# umount -f -a -t linprocfs

Disable the automatic mounting of all instances of procfs in /etc/fstab:
remove or comment out the line(s) of the following form:

proc /proc procfs rw 0 0
proc /compat/linux/proc linprocfs rw 0 0
0
thiamwah
Asked:
thiamwah
  • 4
  • 3
1 Solution
 
jlevieCommented:
As long as you aren't using Linux compatibility mode, then yes it probably should be safe. But you may loose access to some tools that use procfs and information represented there. I don't know that I'd consider that to be a permanent solution. A better long term solution would be to upgrade to a later version (say 4.3 STABLE).
0
 
thiamwahAuthor Commented:
hi jlevie,

I see many directories created by nobody (apache user)
and other users on a daily basis. Please advice.

--- ls -al sampling of /proc ---

dr-xr-xr-x  15 nobody  nogroup   512 Sep  5 13:44 42958
dr-xr-xr-x  15 nobody  nogroup   512 Sep  5 13:44 42959
dr-xr-xr-x  15 nobody  nogroup   512 Sep  5 13:44 42960
dr-xr-xr-x  15 nobody  nogroup   512 Sep  5 13:44 42961
dr-xr-xr-x  15 nobody  nogroup   512 Sep  5 13:44 42962
dr-xr-xr-x  15 nobody  nogroup   512 Sep  5 13:44 42963
dr-xr-xr-x  15 nobody  nogroup   512 Sep  5 13:44 42964
dr-xr-xr-x  15 nobody  nogroup   512 Sep  5 13:44 42965
dr-xr-xr-x  15 nobody  nogroup   512 Sep  5 13:44 42966
dr-xr-xr-x  15 root    wheel     512 Sep  5 13:44 43632
dr-xr-xr-x  15 root    wheel     512 Sep  5 13:44 455
dr-xr-xr-x  15 root    wheel     512 Sep  5 13:44 5
dr-xr-xr-x  15 root    wheel     512 Sep  5 13:44 64075
dr-xr-xr-x  15 root    wheel     512 Sep  5 13:44 64077
dr-xr-xr-x  15 root    wheel     512 Sep  5 13:44 66237
dr-xr-xr-x  15 root    wheel     512 Sep  5 13:44 66370
....


0
 
thiamwahAuthor Commented:
hi jlevie,

I need your expertise in FreeBSD.. :)
can you also look at my other related question at
http://www.experts-exchange.com/jsp/qManageQuestion.jsp?ta=unix&qid=20178625

Thxs!
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
jlevieCommented:
Those represent process information for active processes on the system. It's normal to see them being created and removed as processes start and exit. And that's the problem with unmounting procfs. And tool that needs to access the process information won't work if it can't get to procfs.

The best solution is, as stated above, to upgrade the system to a version that doesn't have the vulnerability. I'd have to check to be certain, but I think that this vulnerability may have been closed by one of the updates to 4.1. If that's the case then you could cvsup your sources for 4.1 to STABLE and re-build the system with 'make world'
0
 
jlevieCommented:
Nope, never mind about the 4.1 STABLE branch. I don't see any evidence that the fix has been applied there.
0
 
thiamwahAuthor Commented:
hi jlevie,

I am a bit paranoid about having to CVSUp the whole source and recompiling them because I tried on a Pentium Celeron with 64 MB ram, and it tooks hours to even download the whole source. And I read comments that it will take another 3.5 hours to recompile the sources. YIKES! :)

Compiling kernels is OK to me but compiling the whole source tree.. !

My production machines are all DELL Dual Pentium 3 CPUs with 512 MB RAM. I wonder how would they fare ? How do I minimize the chances that anything would go wrong inn your experience of cvsuping sources on a prod machine?

Are they any links in your recommendation that I can refer to for this topic? Pls advice!

Thanks a million
0
 
jlevieCommented:
Cvsup'ing the source tree can take quite a while, depending on how fast your Internet link is and how busy the cvs site that you use is. When I'm going to cvsup a system I check connectivity to each of the sites and try the one with the lowest ping RTT. Usually that will be the site that I'll get the best response from. Assming all of your boxes are all "reachable" from each other, you can use one box to to do the cvsup and the compiles. The result can then be installed on the other boxes. The way I do that is to NFS export /usr/src, /usr/obj, & /usr/ports and mount those volumes on the other boxes.

Yeah doing a 'make buildworld' on a 64Mb system will be on the slow side. Doing so on one of you dual processor boxes should be pretty quick as they have a decent about of ram. The advantage of building everything is, of course, that you get all of the updates for all the important stuff. It doesn't update a lot of the userland utilities (X, KDE/Gnome, etc.) that come from the eports collection. But after updating the OS and the ports collection you can pretty easily update anything from the ports collection.
0

Featured Post

Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now