Date: Wed, 30 Jul 2008 13:00:54 +0200 From: Benjamin Lutz <mail@maxlor.com> To: freebsd-security@freebsd.org Cc: Tim Clewlow <tim@clewlow.org> Subject: Re: A new kind of security needed Message-ID: <200807301300.54490.mail@maxlor.com> In-Reply-To: <51075.192.168.1.10.1217298987.squirrel@192.168.1.100> References: <60254.1216921273@critter.freebsd.dk> <f383264b0807281228t7a20861do2f0c150cb5eb67f3@mail.gmail.com> <51075.192.168.1.10.1217298987.squirrel@192.168.1.100>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 29 July 2008 04:36:27 Tim Clewlow wrote: > I'd like to offer a possible solution that I believe can be both > secure and usable. This will use the AID concept outlined above. > > (Note, when I refer to a rwx flag in the following paragraphs, I am > talking about a flag in a 4th group, ie in addition to the normal > user/group/other set of flags, lets call it the app set - in > addition, there is an associated AID for any of the 3 of those flags > that have been set, ie there can be up to 3 different application > ID's set for a single user file) > > When a user file is created, the kernel sets the read flag, and sets > the AID for that flag to 0 (0 being a special value), the intention > being that this means any application can read the file. Next the > kernel sets the the write flag, and set the AID for the write flag > to be the same as the application that is creating the file. (If at > some later time the user wants to limit reading to a single > application, then they can with the equivalent of a chmod for AID) > > Using this method, an errant application will only be able to damage > data files that it owns. It also means if an application wants to > create a new file, then it can. This solves the problems presented > above. (If the file about to be created already exists, then as long > as the application owns the file, it should be allowed to overwrite > it as it should already have write access) Can you elaborate a bit more on what the AID for the x permission is going to look like? Obviously, there have to be applications with very wide-ranging permissions (a filemanager, tools like cp and mv, or the tool used to set AID permissions). Being able to execute them often means being able to change the target file freely and non-interactively (with cp for example). So most applications should not be able to execute cp, right?. However, what about programs whose main job it is to launch other processes, such as /bin/sh. How are you going to prevent some evil application from running /bin/sh -c "cp /dev/zero /very/important/file"? If you're now thinking, limit who can run /bin/sh, consider that some application launching programs can be controlled in other ways; KDE apps can often be controlled with DCOP for example. Cheers Benjamin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200807301300.54490.mail>