linux-kernel - Re: linux-next: manual merge of the audit tree with the security tree

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: <CAHC9VhSKEEyfP7Gc_bsWbwn-TmjBFi3ATLCcx8VjYDSuBTVj5g@mail.gmail.com>
Date:	Fri, 24 Jun 2016 12:20:52 -0400
From:	Paul Moore <paul@...l-moore.com>
To:	Heiko Carstens <heiko.carstens@...ibm.com>
Cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	James Morris <jmorris@...ei.org>, linux-next@...r.kernel.org,
	linux-kernel@...r.kernel.org, Kees Cook <keescook@...omium.org>,
	Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: linux-next: manual merge of the audit tree with the security tree

On Fri, Jun 24, 2016 at 11:20 AM, Heiko Carstens
<heiko.carstens@...ibm.com> wrote:
> On Fri, Jun 24, 2016 at 11:05:33AM -0400, Paul Moore wrote:
>> My immediate concern is making sure that we are at least recording the
>> arguments correctly in the audit record.  My simple tests look okay,
>> but as I said before, I'm far from a s390 expert and your initial
>> comment made it sound like there were still problems with how we were
>> recording the arguments.  Can you either confirm that we are logging
>> the arguments correctly, or provide a suggestion on how to get the
>> right values?  That would be most helpful at this point.
>
> The arguments are correct, except that they are missing sign and zero
> extension to full 64 bit. However I would expect that the audit subsystem
> will only work on the lower 32 bits anyway for compat tasks. So that
> shouldn't be a problem.

Yes, that should be fine.  We were seeing problems with s390 syscalls
on s390x showing garbage in the high 32-bits, that's the problem I'm
trying to solve.

For example, here is a snippet of an audit record generated from
calling the s390 socketcall() on a s390x system:

type=SYSCALL msg=audit(1458835510.860:652): arch=16 syscall=102
 success=yes exit=21
 a0=ffffffff0000000b
 a1=3ff7f82e3c0
 a2=3ff00000000
 a3=a72028

> I'm a bit concerned about user space pointers passed as argument for compat
> tasks. These need to mask out 33 instead of 32 bits.  This is of course
> system call specific and I don't know enough about audit to tell if it
> could be a problem.

>From a practical point of view I'm not sure how much of an impact that
will have as it is unlikely anyone will be doing anything useful with
those pointer values; for example, you aren't going to be inspecting a
process' memory space using just the audit log.  Also, at the very
least we aren't removing any information, just adding in an extra bit
of potential junk.  Anyone who does care about user space pointers in
the audit log, should have all the information the need to drop the
high bit.

Does that sound reasonable?

-- 
paul moore
www.paul-moore.com