Sadly, the `perf trace` command has a dependency on libaudit for a few convenience functions. I'm curious about what people feel the best approach would be here... adding back audit to [community] is ugly since it's not going to work, but building it and statically linking it in the linux-tools package is overly complex.

The lesser evil seems to be adding only a libaudit package... but it's still not going to work if someone tries to use it for what it's intended to do. I'll probably go with this if there's no saner idea. Why not enable audit in your linux-grsec package? Then you can make

On 07/05/14 01:07 AM, Daniel Micay wrote: linux-grsec an optional dependency of the audit userspace tools for people who want to use more than just the convenience functions. I still have an occasional use for audit and the overhead it adds to the kernel is negligible compared to grsecurity itself.

On 07/05/14 05:28 AM, Connor Behan wrote:

...

Sadly, the `perf trace` command has a dependency on libaudit for a few convenience functions. I'm curious about what people feel the best approach would be here... adding back audit to [community] is ugly since it's not going to work, but building it and statically linking it in the linux-tools package is overly complex.

The lesser evil seems to be adding only a libaudit package... but it's still not going to work if someone tries to use it for what it's intended to do. I'll probably go with this if there's no saner idea. Why not enable audit in your linux-grsec package? Then you can make

On 07/05/14 01:07 AM, Daniel Micay wrote: linux-grsec an optional dependency of the audit userspace tools for people who want to use more than just the convenience functions. I still have an occasional use for audit and the overhead it adds to the kernel is negligible compared to grsecurity itself.

RBAC also allows quite a bit of auditing with the grsecurity audit infrastructure. You can audit attempts to make use of a certain path, capability, IP protocol, etc. Of course, this assumes you have a basic working RBAC policy for tacking on allowed + audited policies or disallowed + audited policies. So CONFIG_AUDIT=Y is a lot less useful.

On 05/05/2014 00:56, Daniel Micay wrote:

Sadly, the `perf trace` command has a dependency on libaudit for a few convenience functions. I'm curious about what people feel the best approach would be here... adding back audit to [community] is ugly since it's not going to work, but building it and statically linking it in the linux-tools package is overly complex.

The lesser evil seems to be adding only a libaudit package... but it's still not going to work if someone tries to use it for what it's intended to do. I'll probably go with this if there's no saner idea.

I get a new request[1] about "perf trace" functionality. Are you going to add libaudit to community? Cheers, [1] https://bugs.archlinux.org/task/41690 -- Sébastien "Seblu" Luttringer https://seblu.net GPG: 0x2072D77A

On 26/08/14 03:47 PM, Jan Alexander Steffens wrote:

On Wed, May 7, 2014 at 4:11 PM, Daniel Micay wrote:

...

RBAC also allows quite a bit of auditing with the grsecurity audit infrastructure. You can audit attempts to make use of a certain path, capability, IP protocol, etc. Of course, this assumes you have a basic working RBAC policy for tacking on allowed + audited policies or disallowed + audited policies. So CONFIG_AUDIT=Y is a lot less useful.

I'm sad that AUDIT was disabled. It provided /proc/self/loginuid, which I used in my shell scripts.

loginuid is also used by glibc's getlogin(3), which now no longer works unless the user is logged in on their terminal. In managed X sessions that's often not the case, resulting in bugs like https://bugs.archlinux.org/task/40975 .

I don't think the justification for removing it was good (log spam), but there are good reasons for avoiding AUDITSYSCALL. It forces all system calls on the system call slow path, which has significant overhead. The ugly implementation is also a big security risk. http://lwn.net/Articles/600568/ https://fedorahosted.org/fesco/ticket/1311