On Fri, 2005-01-14 at 14:06, Serge Hallyn wrote: Why require CAP_AUDIT_CONTROL to read the loginuid? Programs like newrole would like to have a more reliable user identity available than the normal uid; we were having them extract the SELinux user identity from the security context, but in Fedora, that is typically just user_u due to the lack of integration of user management with policy. -- Stephen Smalley <sds(a)epoch.ncsc.mil&gt; National Security Agency

--- Stephen Smalley <sds(a)epoch.ncsc.mil&gt; wrote: Since the loginuid identifies the individual who will be held accountable for the action* it should be hidden from untrusted (unprivileged) users to prevent an evil minded program from taking actions based on who will get the blame for them. This was the guidance given us during the Trix B1 evaluation of 1995. ---- * That's right, isn't it? ===== Casey Schaufler casey(a)schaufler-ca.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Move loginuid(accountability information) to the task_struct. Why are you using "loginuid" for accountability ? What if two different users login using the same "loginuid" ? Also, what is the advantage of using NETLINK sockets? It looks like the information is passed to user-space for no-reason. The same information will be passed back to the kernel by the syslog routines. What is the point in doing such processing. Why are you not writing records directly from the kernel to the audit file? Regards Surinder On Fri, 14 Jan 2005 18:58:42 -0600, Serge E. Hallyn <serue(a)us.ibm.com&gt; wrote:

Also, We may or someone else may want to provide advanced filtering (anything more advanced then what is already provided) of audit records before they reach an audit log. Better to do this filtering in userspace via a daemon then in the kernel. We should keep the in-kernel audit subsystem as small and efficient as possible. Anything that can be delegated to userspace should be delegated to userspace. -- Timothy R. Chavez

On Mon, 2005-01-17 at 12:51 -0600, Timothy R. Chavez wrote: I think this is a pretty good idea - there are consequences though.. The number of events that need to be sent across to userspace for processing may be significantly higher than what is finally delivered to the log file, which could be considered by some to be a waste of resources. Eg: If a user is only interested in files in /data/secretstuff, then all the 'normal' file opens conducted by the operating system (which may comprise 99% of events delivered to the daemon), will be dropped by userspace pretty-much instantly - so much of the effort the kernel goes through to write the info to userspace, might be perceived to be wasted. In snare, we generally see single-figure-percentage CPU resource increases in normal operations using this exact approach - however, for some operations (file-open auditing turned on, with many many small-file opens occuring), this can increase to 30% or more. On the other hand, much of that CPU work will have to be done somewhere - the kernel- work. So, we have four alternative approaches here I think: 1) Dumb kernel, smart daemon. (this is the way Snare currently operates) - Audit daemon turns on particular events (eg: file opens) - Kernel sends ANY events that are file-open related to kernel. - Daemon does all the filtering work 2) Semi-intelligent kernel, dumb daemon (Current implementation / LAUS). - Audit daemon turns on particular events, plus some additional event filters (eg: userid, success/failure) - Kernel sends matching events to daemon, which writes the data out appropriately. 3) Intelligent kernel / dumb daemon - Audit daemon turns on particular events, plus some additional event filters: userid, success/failure, wildcard-matched filenames? - Kernel works out fully-qualified file paths, and matches against wildcard match. 4) Semi-intelligent kernel, smart daemon - Audit daemon turns on particular events, plus some additional event filters (eg: userid, success/failure) - Kernel works out fully-qualified file paths, but does not match against wildcard filters. - Kernel sends matching events to daemon, which writes the data out appropriately. - Daemon does MOST of the filtering work - particularly filenames. Sounds like option 4 might be roughly what you're proposing? L. -- Leigh Purdie, Director - InterSect Alliance Pty Ltd http://www.intersectalliance.com/

On Fri, 2005-01-14 at 19:58, Serge E. Hallyn wrote: I'm not sure I follow. First, the current code seems to always set up an audit context by default unless the task is explicitly marked non-auditable. Second, even if an audit context does not exist, you can easily check for a null audit context and just return (uid_t)-1 in that case. The loginuid serves no purpose for non-auditable tasks, and it seems wasteful to put it into the task struct. -- Stephen Smalley <sds(a)epoch.ncsc.mil&gt; National Security Agency

On Tue, 2005-01-18 at 09:48, Steve Grubb wrote: We'd like to have it available for programs like newrole, but that is run from a user session and should thus already be auditable. Given that an audit context is always set up unless the task is explicitly marked non-auditable, and the only task likely to be marked non-auditable is the audit daemon itself, I'm not sure why it matters. Notice that at the point where an audit context is created for the task, we don't have any criteria for determining whether the task should be audited other than the pid and its parent task information. That is why an audit context is almost always created, even if it isn't used in the end. -- Stephen Smalley <sds(a)epoch.ncsc.mil&gt; National Security Agency

No, I guess I've been misreading the code. Now the only remaining reason for keeping that patch is to use loginuid when audit_enabled=0. So I take the patch back :) I will re-diff the netlink-loginuid patch without the loginuid-into- taskstruct.patch and send it back out. thanks, -serge On Tue, 2005-01-18 at 09:55 -0500, Stephen Smalley wrote: -- Serge Hallyn <serue(a)us.ibm.com&gt;

--- Stephen Smalley <sds(a)epoch.ncsc.mil&gt; wrote: Is it impossible for a task to change from non-auditable to auditable without setting the loginuid? Is it possible for an auditable task to perform an auditable action on the behalf of a non-auditable task? An example here might be a non-auditable GUI making a request of the X11 server, or a non-auditable cluster management daemon using a remote service via xinetd. In either case the auditable task needs the loginuid of the non-auditable task in order to ensure that auditing is done properly. I'm sure an evaluation team would get a kick out of finding that in the audit system description. While the loginuid may not be directly useful to a task that never generates audit records it may be useful for other tasks that are doing work on that task's behalf. The audituid of xinetd is rarely interesting. The audituid of a task that makes a request of xinetd is usually interesting. ===== Casey Schaufler casey(a)schaufler-ca.com __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

--- Stephen Smalley <sds(a)epoch.ncsc.mil&gt; wrote: Okay, so if the task is non-auditable (and hence has no loginuid because it has no audit context to contain it) and is made auditable, where will the audituid come from? While network services are the obvious example, I have seen "helper programs" that have the same issue. sudo is the general case of a helper program. If sudo is exec'd by a process with an unset loginuid, who is held accountable for the actions it and its children perform? And I thought that somewhere near the beginning of the thread hucking the loginuid about was the issue. Doesn't matter if it is possible to mark it auditable some time in the future. You could address this issue by making it impossible to change a task from non-auditable to auditable. Or, you can make sure that you always have a loginuid around just in case the task becomes auditable at some point in the future. Either works. If you do it the first way, you'll have to fix it later. You could well be right with regard to the network issues, it's happened before. ===== Casey Schaufler casey(a)schaufler-ca.com __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250

On Tue, 2005-01-18 at 11:15, Serge Hallyn wrote: I don't believe that this is how the current audit code works. An audit context is initially set up for a task upon fork/clone via copy_process-> audit_alloc. audit_alloc calls audit_filter_task to see if the task has auditing completely disabled (which must be explicit; the default is to build a context in the absence of any filters to disable). Unless auditing is completely disabled for the task, audit_alloc creates an audit context for the task, preserves the loginuid from the parent (with my fix), and sets the syscall auditing flag. Subsequently, audit-related information (e.g. paths, inodes, devices) is captured during syscalls made by the task, and at syscall exit, audit_syscall_exit calls audit_get_context, which now checks filters to see if it should mark the context as auditable (and any earlier calls to audit_log during the syscall e.g. by SELinux will have already marked it auditable). If auditable, audit_syscall_exit will then call audit_log_exit to perform the actual logging. It has to work in this way for the reason you describe - we don't know whether the task will trigger any auditable events a priori, so we must set up an audit context and start capturing information unless the task is explicitly marked as not requiring any auditing at all. -- Stephen Smalley <sds(a)epoch.ncsc.mil&gt; National Security Agency

On Fri, 2005-01-14 at 14:06, Serge Hallyn wrote: Do you really need the special case handling for the -1 loginuid? And why include a newline? -- Stephen Smalley <sds(a)epoch.ncsc.mil&gt; National Security Agency

Quoting Stephen Smalley (sds(a)epoch.ncsc.mil): I can manually print out "-1" if that would be nicer for processing, but I really didn't want to print out ~0. Or am I really worrying about nothing? I can take that out... The /proc/$$/ files aren't consistent on how to handle that. -serge

On Fri, 2005-01-14 at 14:06, Serge Hallyn wrote: Shouldn't you be using get_zeroed_page() on the read to avoid leaking data to userspace? Or even do away with allocating a page at all there, e.g. see sel_read_enforce in selinuxfs.c. -- Stephen Smalley <sds(a)epoch.ncsc.mil&gt; National Security Agency