Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1430795

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

From Paul Moore <paul@paul-moore.com>
Newsgroups linux.kernel
Subject Re: linux-next: manual merge of the audit tree with the security tree
Date 2016-06-24 18:30 +0200
Message-ID <rNC9s-1Zd-3@gated-at.bofh.it> (permalink)
References (1 earlier) <rN5ZU-5W6-19@gated-at.bofh.it> <rNfwe-45d-7@gated-at.bofh.it> <rNsa5-45P-3@gated-at.bofh.it> <rNAU1-1d8-15@gated-at.bofh.it> <rNBdn-1jE-1@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, Jun 24, 2016 at 11:20 AM, Heiko Carstens
<heiko.carstens@de.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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: linux-next: manual merge of the audit tree with the security tree Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-06-24 07:50 +0200
  Re: linux-next: manual merge of the audit tree with the security tree Paul Moore <paul@paul-moore.com> - 2016-06-24 17:10 +0200
    Re: linux-next: manual merge of the audit tree with the security tree Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-06-24 17:30 +0200
      Re: linux-next: manual merge of the audit tree with the security tree Paul Moore <paul@paul-moore.com> - 2016-06-24 18:30 +0200
        Re: linux-next: manual merge of the audit tree with the security tree Heiko Carstens <heiko.carstens@de.ibm.com> - 2016-06-25 09:30 +0200

csiph-web