On Fri, 20 Jul 2001, richard offer wrote: > To quote from draft 17 of the Posix spec. > > "The audit events for interfaces that operate on files via file > descriptors include the fd among the data reported. There was some > feeling that this was in itself not very useful, since the file > descriptor is not directly meaningful to an audit administrator, but > the audit record for the open() call that created the file descriptor > is also reportable, and does enable an audit post-processing tool or > audit administrator, to make the link back to a human-readable name." > My concern is that the module must be able to reliably and definitively determine the filename originally specified by the application making the call. I won't repeat the arguments for its necessity, but let me just reiterate "filenames are information" which is mashed, twisted, interpretted, and drawn and quartered to end up with an inode. Since this information is provided in the syscalls from application space, regenerating it when necessary seems to be extra work. Also, the return value to application space is a file descriptor. From this information, locating the inode is obviously possible. Since the "backwards" conversion seems to be difficult in the general case, why not preserve the "forward" case information? Would it be totally unacceptable to put a hook somewhere around line 768 or 770 of ./kernel/open.c to record this information to the module? Also, somewhere around line 835 to record the close? This is very high-level, but provides "raw information" without the need to "rebuild". Based on that thinking, passing the fd to the hooks seems to make a lot more sense to me. The module could identify the inode when the file is opened and simply index into it's own tables to recover it based on fd and PID. It would also see closes so it can remove the relationship from its tables. Resolving the inode from this information is pretty straightforward. Most of the hooks could still pass it and allow the module to do the thinking. There's another possibility... modify the kernel's lookup code to provide all three (filename, fd, inode) and supply it to the module... but this seems somewhat convoluted to me, and may be labelled "invasive". Protections based solely on inode are "solid", but they also throw out information that may be valuable for strategies that provide other forms of protection. As such, there is a clear need to preserve this information and provide it to modules via the interface, imho. The idea of placing hooks as deeply as possible is a good one, but the definition of "possible" comes into question. Caveat... There has been convincing discussion about the risk of duplicating common code in various modules on this list. If several security modules are going to try to rebuild the filename (from inode, file, or fd), it would seem consistant to provide a common means of doing so in the form of a function call to a function in security.c or elsewhere. If any of the people who adamantly contend that such a function can be written based on the information provided to the module currently would submit code to the group for so doing, it may be possible to "have our cake and eat it too". > Without adding the fd to the audit record we make our implementation of > audit non-POSIX compliant, which makes any trusted evaluation a lot more > challenging to have any design accepted by the evaluation team. Um, hrm. POSIX compliance is a technical issue. I'd rather see it actually WORK, but I think pathname/fd registration with the module is useful from a "make it work" perspective. I can't say that "compliance" is not desirable, either... it has significant sales value. If we can do both (work/comply), that would seem valuable. > We are really keen to get the API changed as soon as possible so that we > can start working on the rest of the audit code ready for phase 2. Since we seem to be "getting near a workable interface" right now, this is probably the time to do it, if we're going to. > > What does the rest of the list feel we need to do to have the patch > accepted ? Gee, if I knew THAT... ;) Perhaps straddle the fence... either get a reliable way to convert an fd to an inode with minimal cost or an inode to a fd, would be my guess. The "weight" seems to be fairly evenly split, with inodes being "deeper" and therefore preferred, for the moment. > richard. > > ----------------------------------------------------------------------- > Richard Offer Technical Lead, Trust Technology, SGI > "Specialization is for insects" > _______________________________________________________________________ > Sincerely, J. Melvin Jones |>------------------------------------------------------ || J. MELVIN JONES jmjonesat_private |>------------------------------------------------------ || Microcomputer Systems Consultant || Software Developer || Web Site Design, Hosting, and Administration || Network and Systems Administration |>------------------------------------------------------ || http://www.jmjones.com/ |>------------------------------------------------------ _______________________________________________ linux-security-module mailing list linux-security-moduleat_private http://mail.wirex.com/mailman/listinfo/linux-security-module
This archive was generated by hypermail 2b30 : Fri Jul 20 2001 - 21:19:46 PDT