On Tue, 2005-04-26 at 10:38 -0500, Loulwa F Salem wrote: I just ran through these testcases by hand (just using normal utilities from a shell) using Tim's #7U3 patch against 2.6.12-rc2-mm1. It might be helpful to distinguish which testcases would yield different behaviors if one were to try using the inode-based syscall filters rather than the name-based watches and think about how you might explain to users when they should use one or the other method and how they differ. Some observations: Should be equivalent to putting an inode-based syscall filter on the file, aside from the specific output fields. Only makes sense for the name-based watches. I think that the closest equivalent for inode-based syscall filter would be to monitor file creation syscalls on the parent directory. This also generates a record for the link(2) call on the watched file. That's what I would expect, but you didn't list it above. Note that an inode-based syscall filter would yield the same result for this particular test, but the inode-based filter would persist across reboots (if loaded by auditd on each boot) unlike the watch (which was only on the original file path, unless you explicitly add the new link name to the watch list). Hence, watch-based auditing differs from inode-based filtering in its persistence of tracking of hard links. And actually, the watch-based auditing of access via the hard link would also cease if the incore inode is evicted under memory pressure and then brought incore again later via the link name, right? So how do you explain to users that the watch _may_ be triggered by subsequent accesses via the hard link (until reboot) but can be lost at any time due to memory pressure? Is that the behaviour you want? Should be equivalent to an inode-based filter on the file, as the hard link will share the same inode. This will also generate records for the link(2) call and the unlink(2) call (and if using rm to delete, it will also generate one for access(2) to check file existence and permissions prior to unlinking). Note that an inode-based syscall filter would generate an audit record upon the access to the hard link since the inode is unchanged. Which behavior will most users want? You said "deleted previously" but included the unlink in your expected output. Regardless, if I include the deletion as part of the operation, I get the expected results as well as the access(2) call due to using rm (1). Naturally, this kind of test (creation of a file at a given name) is specific to the watches, but inode-based syscall filter could be used on file creation syscalls on the parent directory. You included the unlink in your expected output, but not the link(2) call for creating the hard link in the first place. As before, inode- based syscall filter could only be used on the parent directory. Plus access(2) if using rm(1) to perform the deletion. Should be equivalent to an inode-based syscall filter on the file. Distinctive to the watch-based approach; inode-based syscall filter could catch the file creation on the parent directory, but would require some kind of userspace assist to set up the filter on the new file. An inode-based syscall filter would continue auditing on the file. What will the users want? Should be equivalent to an inode-based syscall filter on the file, since the inode is unchanged. An inode-based syscall filter would continue auditing access to the file. What concerns me is unclear/unstable semantics and a lack of a clear subdivision between this mechanism and the inode-based syscall filters: - Auditing may or may not be preserved on hard links when using the watches depending on memory pressure, reboots, or whether the watched name is unlinked; is always preserved for inode-based watches. - Auditing is never preserved for renames when using the watches; is always preserved for inode-based watches. - Auditing is automatically enabled for new files when they are created in watched locations when using watches; requires userspace modification to achieve with inode-based watches. -- Stephen Smalley <sds(a)tycho.nsa.gov&gt; National Security Agency

Hello, didn't we have this discussion already a couple of months ago? :-( Anyway, I'll first try to summarize what the CAPP requirements regarding file audit are. More specific comments are embedded below. Fundamentally, files need to be auditable for one of two reasons: - the content is confidential, these are the authentication secrets (/etc/shadow) and the audit log files. - the content integrity is important, these are configuration files that affect the operation of trusted programs. This for example includes: /etc/passwd /etc/shadow /etc/audit.rules /etc/ssh/sshd_config ... Note that /etc/shadow requires both confidentiality and integrity due to its dual role. CAPP doesn't phrase things in exactly these terms since it's more abstract and not specifically tied to a file system. The specific CAPP auditable event requirements are in section 5.1, specifically Table 1, and include: 5.1.3 FAU_SAR.1 "Reading of information from the audit records" 5.1.4 FAU_SAR.2 "Unsuccessful attempts to read information from the audit records" [ These are both about confidentiality ] 5.1.6 FAU_SEL.1 "All modifications to the audit configuration that occur while the audit collection functions are operating" [ Integrity ] 5.2.2 FDP_ACF.1 "All requests to perform an operation on an object covered by the SFP" [ This is the abstract general requirement concerning any type of operation on anything the security target defines to be an "object", these are filesystem objects and IPC objects in this case. The audit log must contain "the identity of the object", device/inode pairs would do here, but having pathnames in addition is clearly useful to tell where the object actually is. ] 5.4.1 FMT_MSA.1 "All modifications of the values of security attributes" ( also 5.4.{2,3,4,5,6,7,8,9} which are similar ) [ A file corresponds to a security attribute based on its path name since that's what the trusted apps refer to, not its device/inode identity. This is where the watch lists are needed. ] In general, whenever a file is confidential, device/inode based audit is appropriate, since that directly corresponds to the file content, and you want access to the content to remain audited even when the file is renamed. That is already addressed by the device/inode based audit rules implemented in LAF. If the file integrity is required, path name based audit is appropriate. Nobody cares if somebody makes a copy of /etc/passwd and modifies the copy. But if someone creates a new version of such a file that is based on a different inode, you need to audit access to the new inode. That's the problem that the watch list based approach solves. You need to be able to reliably audit access to whichever file a certain path name refers to. This is fundamentally related to directory entries and their pointers to other inodes, not the individual file inodes themselves. Hard links confuse the issue a bit, mainly due to the annoying semantics that permit creating a hard link to a file (inode) that you don't have read/write/execute permissions for. The desired behavior with respect to hard links is different for the two auditability requirements. When the integrity is important, you want access to a hard link audited as long as the link is pointing to the same file. When the link is broken (i.e. due to the original name being removed), you don't care anymore about access to the link. You do want audit to start for a new file being created at the old location. When confidentiality is important, you want a hard link to remain audited, even after the link to the original location is broken. We had originally considered supporting persistently stored audit flags (using an extended attribute) for confidential data, but had decided against it since this would only be needed for /etc/shadow and the audit logs in the CAPP configuration. Instead, the evaluated configuration guide contains the requirement that the file systems containing /etc/shadow and the audit logs do not contain any directories writable by untrusted users, this way there is no way for them to create hard links to those files in the first place. Auditing of access to confidential data beyond the very basic CAPP requirements would probably be better solved by a different mechanism such as SELinux policies for people who need that, but this goes beyond CAPP. Embedded comments below... On Thu, Apr 28, 2005 at 03:03:52PM -0400, Stephen Smalley wrote: In the previous discussion, I thought we had reached a consensus that monitoring access to the parent directory on a per-syscall level was too low level to provide a useful audit trail? Loulwa's list wasn't intended to be exhaustive, it just showed specific audit events that the test cases are looking for, with the goal of providing sufficient information to verify if the audit trail is sufficiently complete. There are certainly other combinations of audit events which would meet the requirements. Rebooting is not a problem, you would configure the audit system to add both an inode based audit rule and a watch list for /etc/shadow since it needs audit for both confidentiality and integrity. That way access to the link would still be audited after the reboot. No, that's not the desired behavior, and I had expected that the audit information would be locked in memory to prevent this. It could be worked around by creating both inode based rules and watch lists for trusted databases. It is the expected behavior for files where the admin is interested in integrity but not confidentiality. I would suggest changing the test case to use "write" instead of "read" since that would be the interesting access pattern in that case. You normally won't be auditing read access to /etc/hosts or similar files. The point of the watch list based approach was to avoid the need for invasive (and potentially fragile) userspace modifications. See above, and this test should also use "write" since it's about integrity audit. The point is that you want different behavior depending on the goal of the audit rule, and I agree that it needs to be obvious what the semantics of the audit rules are. Note that nobody is proposing getting rid of the inode based audit rules, you'll need both to meet CAPP requirements. The device/inode pair based rules are fine to meet the FDP_ACF.1 audit requirements, but they are not sufficient to properly handle access to trusted databases. Serge has suggested some more abstract user-space tool to make this less confusing, something like: auditfs add secrecy /etc/shadow (watch the inode) auditfs add integrity /etc/shadow (watch the pathname) and the combination of both would also preserve the secrecy of newly created, renamed, or linked /etc/shadow files. If someone has a different way to solve the integrity/pathname-based audit problem (preferably without needing invasive changes to userspace tools), please share that information. -Klaus

On Mon, 2005-05-02 at 14:15 -0400, Stephen Smalley wrote: Now this is disconcerting - the last time I tried this, not too long ago, I was not able to bind mount files, only directories. Of course if we were going to worry about this, then we should also worry about the simpler 'mount --bind /tmp/evil_etc /etc' or even simpler mounts. Since we don't worry about those, adding extra hooks to deal with the mount bind file case would be unwarrented. (right?) Still the problem is interesting :) And easier to solve than bind mount directory. It should be solvable by hooking security_sb_check_sb, right? What does the fs tree look like at that point? Is shadow simultaneously a vfsmount and a dentry? I agree. How bad would it be to have the kernel create a inode-based audit rule when the new /etc/shadow (or any name-watched file) is created? If we stick with the idea of keeping name- and inode-based watches separate, then the semantics that name-based watches create an inode- based watch whenever a new `name` is created, I think that would be pretty intuitive. How would it be done with selinux? For shadow, I can see a clear solution - it only creates files of type shadow_t under /etc, so a simple type_transition rule with no rewriting of passwd can give you a label to audit on. But for the general case, I would expect you'd need to rewrite application_foo to create the files to be audited with a particular type echo'd into /proc/self/attr/fscreate. Or is there another way selinux could be used? thanks, -serge -- Serge Hallyn <serue(a)us.ibm.com&gt;

On Mon, May 02, 2005 at 02:15:32PM -0400, Stephen Smalley wrote: The memory pressure issue does need to be solved, it's not acceptable that file audit gets disabled when memory is running low. For reboots, the normal way to use the watch list would be to load a set of watches as part of the boot process. Adding a watch to a path adds audit information to the inode corresponding to that path, so as long as the hard link is unbroken, access via the hard link is automatically also audited. In this case you're not losing any information across a reboot and don't need a separate inode based filter. The important difference is that /etc/shadow is recreated whenever an unprivileged user runs the SUID "passwd" program; that's a part of regular system operation and we need to be able to deal with that. But the "passwd" program won't create any bind mounts, and it's a reasonable restriction to tell admins not to do that. My example was misleading, the current watch list approach does handle this appropriately even without an extra inode based rule. Here's an example: add watch for /etc/hosts create hard link: ln /etc/hosts /tmp/hack reboot [ as part of reboot, add watch for /etc/hosts again ] write to /tmp/hack The access to the hard link will generate an audit record, the audit information is associated with the inode when adding the watch list entry. There's no need to add an explicit watch for /tmp/hack to get that audited. I agree that the semantics should be stable, and the preferable solution would be guaranteed audit of access to the inode via hard links as long as any one of the hard links is covered by a watch list entry. That is how the current code works except for the memory pressure issue, and that's on the list of things to fix, right? -Klaus

On Mon, 2005-05-02 at 16:01 -0400, Stephen Smalley wrote: OK, I'll incorporate this with Steve's other suggestions this evening. <snip> -tim

On Fri, 2005-04-29 at 13:16 -0400, Steve Grubb wrote: I think she has plans to do this for functional verification tests. What she's trying to do with these is demonstrate that the auditfs code fufills the CAPP requirement (ie: auditability is preserved given the scenario or not preserved given the scenario). Stephen does bring up a flaw, I believe, where an incore inode can leave because of memory stress, and come back via the hard link, causing us to lose auditability. So I need to address this. -tim