I agree with Dido, most *nix/*nux system compromises are caused by careless programming. A little buffer unhandled could execute arbitrary code therefore leading to a "w00t".
Providing and enforcing permissions to users is a tediuos task for Sysads like us. As far as my knowledge could recall in the example below /home/user1 /home/user1/user2 /home/user1/user3 user1 can handle file and directory permissions of user2 and 3 but with a few group restrictions user2 n 3 cannot cwd. Keech The only thing that --- Rafael 'Dido' Sevilla <[EMAIL PROTECTED]> wrote: > >On Thu, Dec 13, 2001 at 03:22:53PM +0800, Sacha Chua wrote: >> On 13 Dec 2001 08:12:14AM +0800, Rafael 'Dido' Sevilla ([EMAIL PROTECTED]) >said: >> > The biggest single design mistake in Unix. The all-powerful root >> > account. Would have been far better in terms of security to create more >> >> Well, _somebody's_ got to have enough permissions to give other people >> permissions. ;) But yes, there are other models that can give >> finer-grained security. For most uses, though, the Unix model is fine. > >I beg to differ Hermione :). The Unix security model (if it can truly >be flattered with such a title) gives sweeping powers to any program >that needs to do any number of things that are considered privileged, >such as opening raw sockets, binding to port numbers < 1024, changing >uid/gid, or raw access to devices, for instance. For an improperly >written program (and it is by no means a simple task to write a proper >one, especially in C), any mistake in a program that needs to do any of >these things may leave you open to abuse, as everyone here knows and as >many here have experienced directly. I don't consider this an >acceptable situation at all. A mistake in a program like BIND, which >only needs elevated privileges to bind port 53, should not lead to a >total system compromise... > >Patches like LIDS and SELinux try to address the problem. For instance, >a buffer overflow in BIND should only give its exploiter privileges to >bind service ports, and only the service port BIND has been assigned. >And where has that gotten our script kiddie? Precisely nowhere. Same >thing applies to other programs that might be exploitable. Point is: >more fine-grained permissions mitigate the damage security holes can >cause, and the Unix security model is woefully deficient in this regard. >I wouldn't say it's fine for any application that would need to be >connected to the Internet, unless you absolutely trust every program you >have to do only what it needs to do, and every programmer not to make >mistakes when programming. > >-- >Rafael R. Sevilla <[EMAIL PROTECTED]> +63(2) 8177746 ext. 8311 >Programmer, Inter.Net Philippines +63(917) 4458925 >http://dido.ph.inter.net/ OpenPGP Key ID: 0x5CDA17D8 > Heute die Welt und Morgen das Sonnensystem! >_ >Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph >To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] > >To subscribe to the Linux Newbies' List: send "subscribe" in the body to >[EMAIL PROTECTED] _____________________________________________________________ --- http://mail.secureroot.com/ - free mailbox for hackers and geeks _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
