Hi Tom. Thomas Cannon wrote: > That's actually a work in progress. Systrace, from Neils Provos, is a > kernel-level modification that's already part of OpenBSD that monitors > running programs and allows an administrator to define what (and what not) > the program is allowed to do, at the syscall level. So, as in your > example, you could set a policy for 'date' that allows access to read and > set the system time, and that only. So, even if someone had found a way to > subvert 'date' into reading the password file, the exploit would fail as > that wouldn't be something specifically allowed by systrace. The real > benefit is in 3rd party applications. For instance, if there was a hole > found in apache that allowed an attacker to execute code on your server, > the exploit would fail, as the only thing apache would be allowed to do is > bund to port 80, fork children, and serve files from $webroot. If it tried > to execute /bin/sh, it would be denied. Same as if you ran a backdoored > program, like a trojaned './configure' script -- it'd alert you that > something fishy was going on and you could stop it before it did any > damage. > > http://www.citi.umich.edu/u/provos/systrace/ Cool I'll check that out. Although, I think that the existing Linux capabilities would suffice. The kernel already has code in place since 2.2.13, as I recall, to check if a process has a certain capability. But at this point lcap has somewhat of a system wide effect. Correct me if I'm wrong. Maybe each process needs to have the equivalent of /proc/sys/kernel/cap-bound for this to work. Can anyone shed some light on this issue? Anyways it really seems to me like this sort of thing needs to be integrated at each level: kernel, file system, init, etc.. Adding a change of this order to the file system code might be like pulling teeth though. peace, core > -tcannon > > > >>peace, >>core >> >>Kurt Seifried wrote: >> >>>>Is there any point in needing to be root in order to allocate the low >>> >>>ports >>> >>> >>>>on unix-like systems, anymore? Could we get away from having to have some >>>>daemons even have a root stub in order to listen on a low port? What >>> >>>would >>> >>> >>>>break, and what new holes would be created? Could some sort of port ACL >>>>simply be used that says a particular UID can allocate a particular range >>>>of ports? >>> >>> >>>Well. Let's say you don't need to be root anymore. >>> >>>Hey look at me, I'm the webserver! Or the email server, or the ftp server. >>>or the NFS server....... >>> >>>If I can down a service (remote/local DoS), or wait for it to be restarted >>>(like to reload configuration or some other automated interuption) I can be >>>that service. Kind of scary IMHO. >>> >>>Now if you're talking about assigning a UID or GID to "own" the port that's >>>a different story, however I fear people doing well intentioned, but stupid >>>things like assigning it to "nobody". This capability already exists in many >>>systems, Argus Pitbull (for Solaris) and Pitbull LX (for Linux), NSA >>>SELinux, and so on. >>> >>>Personally I like Solaris' ability to assign high ports to require root, >>>this is nice for NFS (2049) and other related systems (has to run as root >>>anyways, well unless you got some really crazy user-daemon nfs =). >>> >>>Plus with privilege seperation (OpenSSH, Postfix, Apache, etc.) there is >>>very little to worry about in most cases, done properly these things are not >>>terribly dangerous (ok, ignoring last week ....=). >>> >>>I wrote an article about this ages ago, but cannot find it, and of course >>>securityportal.com is no more, ohwell. >>> >>> >>> >>>>Discuss. >>>> >>>>BB >>> >>> >>>Kurt Seifried, kurtat_private >>>A15B BEE5 B391 B9AD B0EF >>>AEB0 AD63 0B4E AD56 E574 >>>http://seifried.org/security/ >>>http://www.iDefense.com/ >>> >>> >>> >>> >> >> > > >
This archive was generated by hypermail 2b30 : Fri Jul 05 2002 - 11:57:57 PDT