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: <1357765998.1342.25.camel@localhost>
Date:	Wed, 09 Jan 2013 16:13:18 -0500
From:	Eric Paris <eparis@...hat.com>
To:	Casey Schaufler <casey@...aufler-ca.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 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.  If userspace calls get_last_audit_record() we
might be able to dump the record to auditd.  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/