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


Groups > linux.kernel > #1430753

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

From Heiko Carstens <heiko.carstens@de.ibm.com>
Newsgroups linux.kernel
Subject Re: linux-next: manual merge of the audit tree with the security tree
Date 2016-06-24 17:30 +0200
Message-ID <rNBdn-1jE-1@gated-at.bofh.it> (permalink)
References <rN4hr-4Ia-1@gated-at.bofh.it> <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>
Organization linux.* mail to news gateway

Show all headers | View raw


On Fri, Jun 24, 2016 at 11:05:33AM -0400, Paul Moore wrote:
> >> >> +     audit_syscall_entry(regs->gprs[2], regs->orig_gpr2 & mask,
> >> >> +                         regs->gprs[3] & mask, regs->gprs[4] & mask,
> >> >> +                         regs->gprs[5] & mask);
> >> >
> >> > With these masks it is more correct, however these are still not the values
> >> > used by the system call itself. This would be still incorrect for
> >> > e.g. compat pointers (31 bit on s390).
> >> >
> >> > So it seems like audit_syscall_entry should be called after all sign, zero
> >> > and masking has been done?
> >>
> >> For someone not familiar with s390, compat or not, where would you
> >> suggest we place the audit_syscall_entry() call?
> >
> > I was thinking of a more generic solution for all architectures: for
> > example setting a new TIF flag within do_syscall_trace_enter which
> > indicates that audit_syscall_entry needs be called and then add a
> > conditional call to the SYSCALL_DEFINE and COMPAT_SYSCALL_DEFINE macros.
> >
> > That way audit_syscall_entry would always receive already properly sign and
> > zero extended system call parameters. At the downside this would increase
> > the kernel text size by probably ~370 conditional branches and add two more
> > instructions on the system call hot path.
> >
> > But that's something that could be done independently from your patch,
> > which already improves the current situation.
> 
> 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.

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.

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