Date: Sun, 19 Sep 1999 22:47:46 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net> To: jobe@attrition.org (Jobe) Cc: security@FreeBSD.ORG Subject: Re: Real-time alarms Message-ID: <199909200547.WAA57682@gndrsh.dnsmgr.net> In-Reply-To: <Pine.LNX.3.96.990919193527.13128E-100000@forced.attrition.org> from Jobe at "Sep 19, 1999 10:29:36 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
[CC: trimmed] ...[chop off stuff that we have been over enough]... > [Skip a bit more off the front of this paragraph and get to the meet of things] > If you can prevent processes from > doing things they were never meant to do in the first place, software like > tripwire would not be needed. For example, should login ever need to open > connections to remote machines, or write to files? Granted tripwire is > useful but I think it leaves the overlying problem in OS security design > unresolved. The major security problem related to the *nix OS design is > that arbitrary processes running as uid/euid 0 are given the ability to > access any libc routine, any kernel system call, any ioctl(), load any > code into the working environment etc. If people are really interested in > the integrity of a working environment these are all issues that need to > be addressed. OS security should not be defined in userland policies end > of story. The problem is that most people(Sorry R. Watson) will not take > the initiative to work on in kernel security policies, either out of lack > of time, lack of ambition, or lack of skill. Your totally correct that until we eliminate the ``root has all powers, anyone else has limited powers'' methodology we will be a long way from a securable system. I know that the idea of implementing something along the process priviledge bits in VMS are something that the FreeBSD Principal Architect would love to see in a big way, as well as a dozen or so other people, myself included. However, the implementation of an auditing system should be doable pretty easily in the current system and gain us some functionality that we do not have, and should not need to be changed drastically if or when per process/user privilege becomes a reality, other than it will probably take a privilege to access /dev/audit :-). So lets get back on track and talk about how to implement a real time auditing system in the kernel. Lets forget about any user land consumers of this interface, other than to design the interface in as secure manner as can be given the tools we have today. Lets forget about email and networks, and transports and all that stuff that we already know are not securable _at_ _this_ _time_, and get on with /dev/audit. If someone wants to start the ``per process privilege'' thread up, please do by forking this thread with a subject rename. -- Rod Grimes - KD7CAX - (RWG25) rgrimes@gndrsh.dnsmgr.net Go really fast forward, if you hit a wall, pick up your bits, turn left 90 degrees and do it over... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909200547.WAA57682>