linux-kernel - Re: Friendlier EPERM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50EDE2EC.1080104@schaufler-ca.com>
Date:	Wed, 09 Jan 2013 13:36:44 -0800
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Eric Paris <eparis@...hat.com>
CC:	linux-kernel@...r.kernel.org, libc-alpha@...rceware.org,
	dwalsh@...hat.com, dmalcolm@...hat.com, sds@...ho.nsa.gov,
	segoon@...nwall.com, linux-security-module@...r.kernel.org
Subject: Re: Friendlier EPERM - Request for input

On 1/9/2013 1:13 PM, Eric Paris wrote:
> On Wed, 2013-01-09 at 12:53 -0800, Casey Schaufler wrote:
>
>> Let me try again, I think I didn't quite get the idea across.
>>
>> I'm suggesting that the string returned by get_extended_error_info()
>> ought to be the audit record the system call would generate, regardless
>> of whether the audit system would emit it or not.
>> If the audit record doesn't have the information you need we should
>> fix the audit system to provide it. Any bit of the information in
>> the audit record might be relevant, and your admin or developer might
>> need to see it.
>>
>> I'm suggesting using the audit record because there are tools to
>> examine them and it's a pity to use a different format instead of
>> fixing the one that's already there.
> I get the point.  My problem with using audit records is that they have
> to be stored on disk, forever.  We have to store a record on disk for
> EVERY denial because of rwx bits, acls, capabilities, LSM, etc.  We
> don't do that today and I'm scared of disk growth explosion.  Then we
> could have a kernel interface, say get_last_audit_record(), which could
> query the audit system for that record number.
>
> A thought on disk size explosion might be something like generating
> these records in the kernel and just store them in the task struct until
> some later point in time.

Yes! This is exactly what I'm suggesting.

> If userspace calls get_last_audit_record() we
> might be able to dump the record to auditd.

No! Have reading /proc/self/whatwentwrong return the audit record
associated with the errno last set by the kernel.

> If another record comes
> along we have to free the last one and replace it.  Lot more of a perf
> hit than setting a couple of ints and taking the hit at the time when
> userspace actually wants to collect/use this information.
>
> But are we just building up a rube goldburg machine?  I don't see a
> problem storing the last audit record if it exists, but I don't like
> making audit part of the normal workflow.  I'd do it if others like that
> though....
>
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/