On Mon, Feb 10, 2014 at 12:26 PM, Steve Grubb <sgrubb@xxxxxxxxxx> wrote: > On Monday, February 10, 2014 12:10:27 PM Andrew Lutomirski wrote: >> On Mon, Feb 10, 2014 at 12:06 PM, Steve Grubb <sgrubb@xxxxxxxxxx> wrote: >> > On Monday, February 10, 2014 11:05:38 AM Andrew Lutomirski wrote: >> >> On a default Fedora installation, every system call incurs a fair >> >> amount of overhead due to syscall auditing. This happens despite the >> >> fact that syscalls aren't actually audited, except as part of AVC >> >> denials. >> >> >> >> The overhead is something like 20-40ns per syscall, and the total time >> >> to do a simple syscall with auditing completely disabled is about 70ns >> >> on my laptop. So this is actually a large effect. >> > >> > Then pass -s=nochange on the auditd command prompt. This means that auditd >> > will not attempt to enable auditing. When auditing is not enabled, it will >> > not build an audit context and syscalls are slightly faster, but you will >> > loose a tiny bit of information that selinux would have liked to have. >> > >> >> What would people think about changing the default audit rules to add >> >> something like '-t task,never'? >> > >> > This filter is almost useless. Its never used in real life because it >> > creates inauditable processes which is exactly opposite of what people >> > normally want. >> >> It's also the only way to turn off TIF_SYSCALL_AUDIT in current >> kernels. I'm not attempting to justify the sanity of that; I'm just >> reading the code. > > Not enabling audit also causes TIF_SYSCALL_AUDIT to not be placed in the > process's flags. You have 2 choices: 1) performance 2) audit. They are > necessarily mutually exclusive. > > >> >> This would remove the overhead, but it would come at the cost of >> >> removing >> >> >> >> the syscall records from >> >> /var/log/audit/audit.log when an AVC denial occurs. >> >> >> >> This could make debugging selinux errors a bit harder, but it would be >> >> easy for users to re-enable full auditing. >> >> >> >> I've been playing with fixing this in the kernel, but it's a mess. >> > >> > Its also simple to fix in your config. >> >> There are, indeed, many ways for me to fix this on my machine. I'm >> suggesting that Fedora change the default so that no one has >> experiences this overhead by default. > > There are 3 levels of audit performance degradation. > 1) audit is disabled. You get full speed > 2) audit is enabled and no rules. This is the default for Fedora so that more > information can be collected when AVC's occur. > 3) audit is enabled and rules loaded. This does get a performance hit that can > be measured. In this case, the person wanted auditing and is willing to take > any performance hit it may incur. > > The audit system has been set for #2 for the last 8 or 9 years as a balance > between getting information for avc's, not taking a big performance hit, and > keeping setup easy for when people want to add auditing to their system. > Right. I'm proposing changing the default from #2 to #1. I think that #2-by-default is a terrible tradeoff. I suspect I've debugged more selinux denials than the average user, and I have *never* *once* looked at a 'syscall' entry in the log. I think that subjecting every Fedora user by default to 20-40 ns of extra syscall latency for the sole benefit of getting those 'syscall' messages is a bad tradeoff. I'm willing to write kernel code to improve the situation. The problem is that getting rid of TIF_SYSCALL_AUDIT when there are no audit rules configured is messy. Better suggestions are welcome. > >> If the default gets changed, I >> don't particularly care *which* change is made, so long as the effect >> is that TIF_SYSCALL_AUDIT doesn't get set (so there's no overhead) but >> that AVC denials still get logged (which I suspect is the overwhelming >> majority of the value added by audit support). > > AVC's should be logged with or without audit being enabled. Auditd will > collect any avc sent to it by selinux even if audit is disabled. Please try > adding -s=nochange to your config and see how that works for you. I will not be at all surprised if it works. > > -Steve -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
