On Thu, May 29, 2014 at 6:05 AM, Steve Grubb <sgr...@redhat.com> wrote: > On Wednesday, May 28, 2014 07:40:57 PM Andy Lutomirski wrote: >> >> - It assumes that syscall numbers are between 0 and 2048. >> >> >> > There could well be a bug here. Not questioning that. Although that >> > would be patch 1/2 >> >> Even with patch 1, it still doesn't handle large syscall numbers -- it >> just assumes they're not audited. > > All syscalls must be auditable. Meaning that if an arch goes above 2048, then > we'll need to do some math to get it to fall back within the range. >
Off the top of my head, x32, some ARM variants, and some MIPS variants have syscalls above 2048. auditsc has been disabled on the offending ARM variant (because I noticed that the same issue affects seccomp, and no one particularly wants to fix it), but I suspect that auditsc is enabled but completely broken on whichever MIPS ABI has the issue. I haven't checked. TBH, I think that it's silly to let the auditsc design be heavily constrained by ia64 considerations -- I still think that the syscall entry hooks could be removed completely with some effort on most architectures and that performance would improve considerably. For users who don't have syscall filter rules, performance might even improve on ia64 -- I don't care how expensive syscall_get_args is, the actual printk/auditd thing will dominate in cases where anything is written. I wonder whether the syscall restart mechanism can be used to thoroughly confused auditsc. I don't really know how syscall restarts work. My point is: I don't know what guarantees auditsc is supposed to provide, nor do I know how to evaluate whether the code is correct. For users who aren't bound by Common Criteria or related things, I suspect that syscall auditing (as opposed to, say, LSM-based auditing) will provide dubious value at best. Keep in mind that many syscalls take pointer arguments, and the auditsc code can't really do anything sensible with them. > >> >> - It's unclear whether it's supposed to be reliable. >> >> >> > Unclear to whom? >> >> To me. >> >> If some inode access or selinux rule triggers an audit, is the auditsc >> code guaranteed to write an exit record? And see below... > > It should or indicate that it could not. > --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/