- 08 May, 2013 2 commits
-
-
Jeff Layton authored
Jiri reported a regression in auditing of open(..., O_CREAT) syscalls. In older kernels, creating a file with open(..., O_CREAT) created audit_name records that looked like this: type=PATH msg=audit(1360255720.628:64): item=1 name="/abc/foo" inode=138810 dev=fd:00 mode=0100640 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 type=PATH msg=audit(1360255720.628:64): item=0 name="/abc/" inode=138635 dev=fd:00 mode=040750 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 ...in recent kernels though, they look like this: type=PATH msg=audit(1360255402.886:12574): item=2 name=(null) inode=264599 dev=fd:00 mode=0100640 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 type=PATH msg=audit(1360255402.886:12574): item=1 name=(null) inode=264598 dev=fd:00 mode=040750 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 type=PATH msg=audit(1360255402.886:12574): item=0 name="/abc/foo" inode=264598 dev=fd:00 mode=040750 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 Richard bisected to determine that the problems started with commit bfcec708, but the log messages have changed with some later audit-related patches. The problem is that this audit_inode call is passing in the parent of the dentry being opened, but audit_inode is being called with the parent flag false. This causes later audit_inode and audit_inode_child calls to match the wrong entry in the audit_names list. This patch simply sets the flag to properly indicate that this inode represents the parent. With this, the audit_names entries are back to looking like they did before. Cc: <stable@vger.kernel.org> # v3.7+ Reported-by: Jiri Jaburek <jjaburek@redhat.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Test By: Richard Guy Briggs <rbriggs@redhat.com> Signed-off-by: Eric Paris <eparis@redhat.com>
-
Eric W. Biederman authored
audit rule additions containing "-F auid!=4294967295" were failing with EINVAL because of a regression caused by e1760bd5. Apparently some userland audit rule sets want to know if loginuid uid has been set and are using a test for auid != 4294967295 to determine that. In practice that is a horrible way to ask if a value has been set, because it relies on subtle implementation details and will break every time the uid implementation in the kernel changes. So add a clean way to test if the audit loginuid has been set, and silently convert the old idiom to the cleaner and more comprehensible new idiom. Cc: <stable@vger.kernel.org> # 3.7 Reported-By: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Tested-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Eric Paris <eparis@redhat.com>
-
- 30 Apr, 2013 12 commits
-
-
Eric Paris authored
The userspace audit tools didn't like the existing formatting of the AUDIT_ANOM_LINK event. It needed to be expanded to emit an AUDIT_PATH event as well, so this implements the change. The bulk of the patch is moving code out of auditsc.c into audit.c and audit.h for general use. It expands audit_log_name to include an optional "struct path" argument for the simple case of just needing to report a pathname. This also makes audit_log_task_info available when syscall auditing is not enabled, since it is needed in either case for process details. Signed-off-by: Kees Cook <keescook@chromium.org> Reported-by: Steve Grubb <sgrubb@redhat.com>
-
Eric Paris authored
This function is called when we receive a netlink message from userspace. We don't need to worry about it coming from irq context or irqs making it re-entrant. Signed-off-by: Eric Paris <eparis@redhat.com>
-
Eric Paris authored
We were doing spin_lock_irq and spin_unlock_irq. This is STOOPID. If we were in interupt context we were already screwed and called panic() in do_exit(). So the irq stuff is useless. Also, these values can only be changed by receiving a netlink message from current. Since we are in do_exit() clearly we aren't in the syscall sending the netlink message to change these values. Thus, just read them and go with it. Signed-off-by: Eric Paris <eparis@redhat.com>
-
Eric Paris authored
current->signal->audit_* can only change from a netlink message from current. Obviously in this case we cannot be handling a netlink message from current. So there is no change these can change under us. No need to take a lock to read them. Signed-off-by: Eric Paris <eparis@redhat.com>
-
Richard Guy Briggs authored
Most commands are entered one line at a time and processed as complete lines in non-canonical mode. Commands that interactively require a password, enter canonical mode to do this while shutting off echo. This pair of features (icanon and !echo) can be used to avoid logging passwords by audit while still logging the rest of the command. Adding a member (log_passwd) to the struct audit_tty_status passed in by pam_tty_audit allows control of canonical mode without echo per task. Signed-off-by: Richard Guy Briggs <rgb@redhat.com> Signed-off-by: Eric Paris <eparis@redhat.com>
-
Eric Paris authored
Some of the callers of the audit tty function use spin_lock_irqsave/restore. We were using the forced always enable version, which seems really bad. Since I don't know every one of these code paths well enough, it makes sense to just switch everything to the safe version. Maybe it's a little overzealous, but it's a lot better than an unlucky deadlock when we return to a caller with irq enabled and they expect it to be disabled. Signed-off-by: Eric Paris <eparis@redhat.com>
-
Eric Paris authored
-
Eric Paris authored
We have a number of places we were reimplementing the same code to write out lsm labels. Just do it one darn place. Signed-off-by: Eric Paris <eparis@redhat.com>
-
Eric Paris authored
Since we are always current, we can push a lot of this stuff to the bottom and get rid of useless interfaces and arguments. Signed-off-by: Eric Paris <eparis@redhat.com>
-
Eric Paris authored
We always use current. Stop pulling this when the skb comes in and pushing it around as arguments. Just get it at the end when you need it. Signed-off-by: Eric Paris <eparis@redhat.com>
-
Eric Paris authored
We used to have an inflexible mechanism to add audit rules to the kernel. It hasn't been used in a long time. Get rid of that stuff. Signed-off-by: Eric Paris <eparis@redhat.com>
-
Eric Paris authored
We have 2 interfaces to send audit rules. Rather than check validity of things in 2 places make a helper function. Signed-off-by: Eric Paris <eparis@redhat.com>
-
- 16 Apr, 2013 2 commits
-
-
Eric Paris authored
When userspace sends messages to the audit system it includes a type. We want to be able to filter messages based on that type without have to do the all or nothing option currently available on the AUDIT_FILTER_TYPE filter list. Instead we should be able to use the AUDIT_FILTER_USER filter list and just use the message type as one part of the matching decision. Signed-off-by: Eric Paris <eparis@redhat.com>
-
Eric Paris authored
Looks like this one has been around since 5195d8e2: kernel/auditsc.c: In function ‘audit_free_names’: kernel/auditsc.c:998: error: ‘i’ undeclared (first use in this function) ...and this warning: kernel/auditsc.c: In function ‘audit_putname’: kernel/auditsc.c:2045: warning: ‘i’ may be used uninitialized in this function Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Eric Paris <eparis@redhat.com>
-
- 12 Apr, 2013 1 commit
-
-
Gao feng authored
audit_enabled has already been exported in include/linux/audit.h. and kernel/audit.h includes include/linux/audit.h, no need to export aduit_enabled again in kernel/audit.h Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com> Signed-off-by: Eric Paris <eparis@redhat.com>
-
- 11 Apr, 2013 2 commits
-
-
Eric Paris authored
RHBZ: 785936 If the audit system collects a record about one process sending a signal to another process it includes in that collection the 'secid' or 'an int used to represet an LSM label.' If there is no LSM enabled it will collect a 0. The problem is that when we attempt to print that record we ask the LSM to convert the secid back to a string. Since there is no LSM it returns EOPNOTSUPP. Most code in the audit system checks if the secid is 0 and does not print LSM info in that case. The signal information code however forgot that check. Thus users will see a message in syslog indicating that converting the sid to string failed. Add the right check. Signed-off-by: Eric Paris <eparis@redhat.com>
-
Eric Paris authored
Userspace parsing libraries assume that msg= is only for userspace audit records, not for user tty records. Make this consistent with the other tty records. Reported-by: Steve Grubb <sgrubb@redhat.com> Signed-off-by: Eric Paris <eparis@redhat.com>
-
- 10 Apr, 2013 6 commits
-
-
Andrew Morton authored
> In function audit_alloc_context(), use kzalloc, instead of kmalloc+memset. Patch also renames audit_zero_context() to > audit_set_context(), to represent it's inner workings properly. Fair enough. I'd go futher... Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Eric Paris <eparis@redhat.com> Cc: Rakib Mullick <rakib.mullick@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Eric Paris <eparis@redhat.com>
-
Rakib Mullick authored
In function audit_alloc_context(), use kzalloc, instead of kmalloc+memset. Patch also renames audit_zero_context() to audit_set_context(), to represent it's inner workings properly. Signed-off-by: Rakib Mullick <rakib.mullick@gmail.com> Signed-off-by: Eric Paris <eparis@redhat.com>
-
Chen Gang authored
__audit_socketcall is an extern function. better to check its parameters by itself. also can return error code, when fail (find invalid parameters). also use macro instead of real hard code number also give related comments for it. Signed-off-by: Chen Gang <gang.chen@asianux.com> [eparis: fix the return value when !CONFIG_AUDIT] Signed-off-by: Eric Paris <eparis@redhat.com>
-
Dmitry Monakhov authored
filename should be destroyed via final_putname() instead of __putname() Otherwise this result in following BUGON() in case of long names: kernel BUG at mm/slab.c:3006! Call Trace: kmem_cache_free+0x1c1/0x850 audit_putname+0x88/0x90 putname+0x73/0x80 sys_symlinkat+0x120/0x150 sys_symlink+0x16/0x20 system_call_fastpath+0x16/0x1b Introduced-in: 7950e385Signed-off-by: Dmitry Monakhov <dmonakhov@openvz.org> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Eric Paris <eparis@redhat.com>
-
Anton Blanchard authored
Some distros enable auditing by default which forces us through the syscall trace path. Remove the static branch prediction in our 64bit syscall handler and let the hardware do the prediction. Signed-off-by: Anton Blanchard <anton@samba.org> Signed-off-by: Eric Paris <eparis@redhat.com>
-
Anton Blanchard authored
Commit b05d8447 (audit: inline audit_syscall_entry to reduce burden on archs) changed audit_syscall_entry to check for a dummy context before calling __audit_syscall_entry. Unfortunately the dummy context state is maintained in __audit_syscall_entry so once set it never gets cleared, even if the audit rules change. As a result, if there are no auditing rules when a process starts then it will never be subject to any rules added later. x86 doesn't see this because it has an assembly fast path that calls directly into __audit_syscall_entry. I noticed this issue when working on audit performance optimisations. I wrote a set of simple test cases available at: http://ozlabs.org/~anton/junkcode/audit_tests.tar.gz 02_new_rule.py fails without the patch and passes with it. The test case clears all rules, starts a process, adds a rule then verifies the process produces a syscall audit record. Signed-off-by: Anton Blanchard <anton@samba.org> Cc: <stable@kernel.org> # 3.3+ Signed-off-by: Eric Paris <eparis@redhat.com>
-
- 08 Apr, 2013 4 commits
-
-
Richard Guy Briggs authored
The kauditd_thread() task was started only after the auditd userspace daemon registers itself with kaudit. This was fine when only auditd consumed messages from the kaudit netlink unicast socket. With the addition of a multicast group to that socket it is more convenient to have the thread start on init of the kaudit kernel subsystem. Signed-off-by: Richard Guy Briggs <rbriggs@redhat.com> Signed-off-by: Eric Paris <eparis@redhat.com>
-
Richard Guy Briggs authored
The wait queue control code in kauditd_thread() was nested deeper than necessary. The function has been flattened for better legibility. Signed-off-by: Richard Guy Briggs <rbriggs@redhat.com> Signed-off-by: Eric Paris <eparis@redhat.com>
-
Richard Guy Briggs authored
The hold queue flush code is an autonomous chunk of code that can be refactored, removed from kauditd_thread() into flush_hold_queue() and flattenned for better legibility. Signed-off-by: Richard Guy Briggs <rbriggs@redhat.com> Signed-off-by: Eric Paris <eparis@redhat.com>
-
Matvejchikov Ilya authored
It is useful to extend GID/EGID comparation logic to be able to match not only the exact EID/EGID values but the group/egroup also. Signed-off-by: Matvejchikov Ilya <matvejchikov@gmail.com> Signed-off-by: Eric Paris <eparis@redhat.com>
-
- 18 Feb, 2013 3 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/inputLinus Torvalds authored
Pull input subsystem fixes from Dmitry Torokhov: "Two small driver fixups and a documentation update for managed input devices" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: Input: wacom - fix wacom_set_report retry logic Input: document that unregistering managed devices is not necessary Input: lm8323 - fix checking PWM interrupt status
-
Linus Torvalds authored
Commit c060f943 ("mm: use aligned zone start for pfn_to_bitidx calculation") fixed out calculation of the index into the pageblock bitmap when a !SPARSEMEM zome was not aligned to pageblock_nr_pages. However, the _allocation_ of that bitmap had never taken this alignment requirement into accout, so depending on the exact size and alignment of the zone, the use of that index could then access past the allocation, resulting in some very subtle memory corruption. This was reported (and bisected) by Ingo Molnar: one of his random config builds would hang with certain very specific kernel command line options. In the meantime, commit c060f943 has been marked for stable, so this fix needs to be back-ported to the stable kernels that backported the commit to use the right alignment. Bisected-and-tested-by: Ingo Molnar <mingo@kernel.org> Acked-by: Mel Gorman <mgorman@suse.de> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
- 15 Feb, 2013 8 commits
-
-
Linus Torvalds authored
Merge tag 'stable/for-linus-3.8-rc7-tag-two' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen Pull xen fixes from Konrad Rzeszutek Wilk: "Two fixes: - A simple bug-fix for redundant NULL check. - CVE-2013-0228/XSA-42: x86/xen: don't assume %ds is usable in xen_iret for 32-bit PVOPS and two reverts: - Revert the PVonHVM kexec. The patch introduces a regression with older hypervisor stacks, such as Xen 4.1." * tag 'stable/for-linus-3.8-rc7-tag-two' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen: Revert "xen PVonHVM: use E820_Reserved area for shared_info" Revert "xen/PVonHVM: fix compile warning in init_hvm_pv_info" xen: remove redundant NULL check before unregister_and_remove_pcpu(). x86/xen: don't assume %ds is usable in xen_iret for 32-bit PVOPS.
-
Mauro Carvalho Chehab authored
As reported by Klaus Schmidinger: "In VDR I use an ioctl() call with FE_READ_UNCORRECTED_BLOCKS on a device (using stb0899). After this call I check 'errno' for EOPNOTSUPP to determine whether this device supports this call. This used to work just fine, until a few months ago I noticed that my devices using stb0899 didn't display their signal quality in VDR's OSD any more. After further investigation I found that ioctl(FE_READ_UNCORRECTED_BLOCKS) no longer returns EOPNOTSUPP, but rather ENOTTY. And since I stop getting the signal quality in case any unknown errno value appears, this broke my signal quality query function." While the changes reflect what is there at: http://comments.gmane.org/gmane.linux.kernel/1235728 it does cause regression on userspace. So, revert it to stop the damage. This reverts commit 177ffe50 ("[media] dvb_frontend: return -ENOTTY for unimplement IOCTL"). Reported-by: Klaus Schmidinger <Klaus.Schmidinger@tvdr.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparcLinus Torvalds authored
Pull sparc fixes from David Miller: "A couple small fixes for sparc including some THP brown-paper-bag material: 1) During the merging of all the THP support for various architectures, sparc missed adding a HAVE_ARCH_TRANSPARENT_HUGEPAGE to it's Kconfig, oops. 2) Sparc needs to be mindful of hugepages in get_user_pages_fast(). 3) Fix memory leak in SBUS probe, from Cong Ding. 4) The sunvdc virtual disk client driver has a test of the bitmask of vdisk server supported operations which was off by one bit" * git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc: sunvdc: Fix off-by-one in generic_request(). sparc64: Fix get_user_pages_fast() wrt. THP. sparc64: Add missing HAVE_ARCH_TRANSPARENT_HUGEPAGE. sparc: kernel/sbus.c: fix memory leakage
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull one more x86 fix from Peter Anvin: "Sigh. One more patch in the "please don't brick my Samsung" series" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi: Clear EFI_RUNTIME_SERVICES rather than EFI_BOOT by "noefi" boot parameter
-
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pciLinus Torvalds authored
Pull PCI fix from Bjorn Helgaas: "This is another fix for v3.8. It fixes an oops that happens when a Thunderbolt adapter is unplugged (remove device, poll for PME events on no-longer-existing device, oops)." * tag '3.8-pci-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: PCI/PM: Clean up PME state when removing a device
-
git://gitorious.org/linux-omap-dss2/linuxLinus Torvalds authored
Pull omapdss fixes from Tomi Valkeinen: "It'd be great if these two late fixes would still make it into 3.8. The other one fixes ARM kernel compilation when using 'allyesconfig', and the other makes DPI displays function again on OMAP3630 boards: - Fix ARM compilation with "allyesconfig" (omapdrm: fix the dependency to omapdss) - fix DPI displays on OMAP3630 (OMAPDSS: add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list)" * tag 'omapdss-for-3.8-rc8' of git://gitorious.org/linux-omap-dss2/linux: omapdrm: fix the dependency to omapdss OMAPDSS: add FEAT_DPI_USES_VDDS_DSI to omap3630_dss_feat_list
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull i2c maintainer info update from Wolfram Sang: "Since my old email and repos are not working anymore, and this already caused some confusion, I think a MAINTAINERS update for 3.8 is helpful. So, people trying I2C with the new kernel can properly reach me and find my repos." * 'i2c/for-current' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: MAINTAINERS: change my email and repos
-
Konrad Rzeszutek Wilk authored
This reverts commit 9d02b43d. We are doing this b/c on 32-bit PVonHVM with older hypervisors (Xen 4.1) it ends up bothing up the start_info. This is bad b/c we use it for the time keeping, and the timekeeping code loops forever - as the version field never changes. Olaf says to revert it, so lets do that. Acked-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
-