Hello First of all i did not express myself very clear: (for the ones who replied), i said virtual shared environment, not virtual machine, so i am not talking about VMware or other software like that. My main concern is the security in a server (eg webhosting provider), where multiple users are hosted, and everybody must be restricted to get out of his own home. The jail(8) solution seems fair to me, because i use FreeBSD on all servers, i will read the article. I was aiming for a much easier solution like configuring httpd.conf, php.ini, etc in that way that i could do all written above. I know and i understand that php does not provide a secure environment. The problems with the scripts bugs on the bugtraq doesnt concern me (as an administrator), if the user does not know how to secure his script, that is of course, his own private bussines. That _IS NOT_ php's fault.
I have not tried Plesk yet, only a demo, it might provide a secure environment, but you still need to adjust some things. I am currently running FreeBSD 4.9-STABLE with Cpanel (latest) as an admin panel (for endusers). My oppinion is that if you really want to transfer files secure, than you can do this via 80, file uploading, but this is painfull for the enduser. Thanks everybody for help, ill be reading the paper and tell you my opinion. I'll be happy yo discuss more about webapp security. Serban ##Fastweb## > I wrote an article for USENIX :login; on FreeBSD jails a couple years ago. > It describes their capabilities and why you might want to use them. > http://www.usenix.org/publications/login/2002-06/pdfs/hope.pdf > > I don't think you have to be a member to get that publication online, now > that the article is more than a year old. > > Note that 'chroot' and 'jail' are two TOTALLY different things. > Unfortunately, a lot of people talk about 'chroot jails', which makes > things > slightly confusing. 'chroot' exists on most unixes. Virtually any chroot > environment can be escaped if the process uses a privilege escalation > attack > and gains root. Furthermore, if a process in a 'chroot' environment > manages > to escalate privileges and get to root, it can kill other processes on the > box, create a /dev/mem device inside it's chroot and then go read memory, > and do practically anything it wants. > > 'jail' is totally different. Processes cannot escape a 'jail', even if > they > escalate their privileges to root! (Note that there was a recent bug > discovered in this mechanism, so you have to be up-to-date on FreeBSD for > that claim to be true.) 'jail' exists exclusively in FreeBSD. Not even > the > other BSD variants (NetBSD, OpenBSD, Darwin) have it. > > When processes run in jail(8), they can't do a bunch of things: > - open raw sockets > - affect processes other than the ones in their own jail > - cause packets to originate with any IP address other than the jail's IP > - see files outside their filesystem > - open raw devices (e.g. /dev/rda0) > - make devices (e.g. /dev/mem) > > I'd urge you to read my USENIX paper, or read my book on FreeBSD security > (coming out from O'Reilly in the fall) on how to do jails well. > > More comments inline: > > On 3/31/04 4:49 AM, "Dave Paris" <[EMAIL PROTECTED]> wrote: >>> -you dont want anyone to get out of his 'box' (eg /home/sasha/) >> >> use 'chroot' jails > > They can be escaped trivially if you gain root. You need jail(8) on > FreeBSD > to actually make that true. > >>> -you want to allow php, perl or other web languages to run safely >> >> "PHP" and "run safely" in the same sentence? Have you perused Bugtraq >> lately? > > If apache runs in a jail(8), then you can at least limit the extent of the > damage. While the bugs are still there, only the particular jail's data > is > at risk. Thus, if a user who is jail(8)'ed insists on having access to > PHP, > only that user's data is at risk. > >>> My problem is that i tested some script-kiddies local exploits >>> (php,perl) >>> and the system is vulnerable, the user can get out of his box and >>> see system files (etc/passwd, other dirs). > > Exploits will still work, to some extent, inside a jail. However, your > jail > can have a password file that only has one entry: the user. (The real > system has a totally different password file) Again, you haven't nullified > the privilege escalation attack, but you have reduced the exposure to a > single user's password, and you've limited the damage that can be done to > just that user's files. > > This seems to be more a 'secure system administration' thread more than a > 'secure coding' thread. > > Paco > -- > Paco Hope, CISSP > Senior Software Security Consultant > Cigital, Inc. http://www.cigital.com/ > [EMAIL PROTECTED] -- +1.703.404.5769 > > > > ---------------------------------------------------------------------------- > This electronic message transmission contains information that may be > confidential or privileged. The information contained herein is intended > solely for the recipient and use by any other party is not authorized. If > you are not the intended recipient (or otherwise authorized to receive > this > message by the intended recipient), any disclosure, copying, distribution > or > use of the contents of the information is prohibited. If you have > received > this electronic message transmission in error, please contact the sender > by > reply email and delete all copies of this message. Cigital, Inc. accepts > no > responsibility for any loss or damage resulting directly or indirectly > from > the use of this email or its contents. > Thank You. > ---------------------------------------------------------------------------- > > > > --
