Re: PaX options required by clamav
Jens Kasten <[email protected]> Wed, 28 Aug 2013 16:48:59 +0200
| Newsgroups | gmane.linux.rsbac |
|---|---|
| Message-ID | <[email protected]> |
I hit also this bug when pax is enabled. I asked the paxteam and this I got: >>actually, i just figured it out. the bug is that >>linux_dazuko_device_write >>copies the 'buffer' content into the kernel via xp_copyin (so far so >>good), >>but it still passes 'buffer' to dazuko_get_value instead of >>'tmpbuffer'. >>from what i recall, the VFS does verify the userland supplied pointer >>so >>this is not a security issue per se (but it can still oops the >>kernel). >>you guys had better audit all the VFS callbacks for this kind of >>problem, >>and even better would be if you used __user annotations and ran sparse >>on >>this code to find similar problems Its looks like this is rsbac related. Its only is present with dazuko with clamd. Am Montag, den 29.04.2013, 17:37 +0200 schrieb Javier Juan Martínez Cabezón: > On 29/04/13 09:58, Amon Ott wrote: > > > > > Thank you for finding this out and clarifying! > > > Right, softmode is a difficult thing. We could do this, similar to CAP > > behaviour. However, if you switch it off afterwards, the processes keep > > running with more rights that they should have, leaving you with a false > > sense of security. So we would have to go through the process list and > > reset the flags according to the executed program. Possible, but > > annoying with potential to kill half finished jobs. > > > Don't spend your time with this Amon, just the information about what > PaX softmode does is needed to don't get confused if you suppose > something that don't happen (I got check disabling PaX Flags with clamd, > but it stills got killed), my mistake was to think after this that PaX > Softmode would do something that was not. I finished testing PaX as the > trouble source when I switch it Softmode and it stills killing it. > Knowing this It's trivial to change PaX Flags to perms to testing and > with ldd test one by one any library it uses searching for and if not > check some hardcoded PaX options (as UDEREF could be). > > > Thanks once more for all this info. Our handbook could need a lot of > > caring attention. So much work to do and so little time. We would need > > some volunteer or some funded worker to do all the docs properly - and > > continuously over years. So far we have had several volunteers for docs, > > but all of them could not go on for various reasons. > > > > Amon. > > If you wish I could try as volunteer, I'm just a Laboratory technician > (healthcare personnel), and because of this I have not studies in > computer science area, and in consequence I can't give you warranties > about what I'm doing (if a is secure at this way or not). I can warrant > you one thing, I will do my best. > > If you want we can use the mail list to send the "patches" in > documentation and if approved by you, merge changes (my english is not > perfect o we could use this to correct mistakes too). > > I would need access to the wiki to do it myself. > > > _______________________________________________ > rsbac mailing list > [email protected] > http://www.rsbac.org/mailman/listinfo/rsbac _______________________________________________ rsbac mailing list [email protected] http://www.rsbac.org/mailman/listinfo/rsbac
clamd_with_dazuko_bug
(text/plain, 4.3 KB)
Aug 28 14:16:24 localhost kernel: PAX: please report this to [email protected] Aug 28 14:16:24 localhost kernel: BUG: unable to handle kernel paging request at 000002dffbcf3b40 Aug 28 14:16:24 localhost kernel: IP: [<ffffffff81085eea>] dazuko_get_value+0x3a/0x130 Aug 28 14:16:24 localhost kernel: PGD 186292000 Aug 28 14:16:24 localhost kernel: Thread overran stack, or stack corrupted Aug 28 14:16:24 localhost kernel: Oops: 0000 [#5] SMP Aug 28 14:16:24 localhost kernel: Modules linked in: sch_cbq nfsv4 act_police cls_flow cls_fw cls_u32 sch_tbf sch_prio sch_htb sch_hfsc sch_ingress sch_sfq xt_LOG xt_time xt_connlimit xt_realm xt_addrtype iptable_raw xt_comment xt_recent xt_nat ipt_ULOG ipt_REJECT ipt_MASQUERADE ipt_ECN ipt_CLUSTERIP ipt_ah nf_nat_tftp nf_nat_snmp_basic nf_conntrack_snmp nf_nat_sip nf_nat_pptp nf_nat_proto_gre nf_nat_irc nf_nat_h323 nf_nat_ftp nf_nat_amanda ts_kmp nf_conntrack_amanda nf_conntrack_sane nf_conntrack_tftp nf_conntrack_sip nf_conntrack_proto_sctp nf_conntrack_pptp nf_conntrack_proto_gre nf_conntrack_netlink nf_conntrack_netbios_ns nf_conntrack_broadcast nf_conntrack_irc nf_conntrack_h323 nf_conntrack_ftp xt_TPROXY nf_tproxy_core xt_tcpmss xt_pkttype xt_physdev xt_owner xt_NFQUEUE xt_NFLOG xt_multiport xt_mac xt_limit xt_length xt_iprange xt_helper xt_hashlimit xt_DSCP xt_dscp xt_dccp xt_conntrack xt_connmark xt_CLASSIFY xt_state iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack iptable_mangle iptable_filter ip_tables vhost_net nfsd auth_rpcgss oid_registry exportfs nfs_acl kvm_amd kvm libcrc32c nfs lockd sunrpc usb_storage Aug 28 14:16:24 localhost kernel: CPU: 0 PID: 14237 Comm: clamd Tainted: G D 3.10.9-rsbac-3.1+ #8 Aug 28 14:16:24 localhost kernel: Hardware name: To Be Filled By O.E.M. ALiveSATA2-GLAN/ALiveSATA2-GLAN, BIOS P2.50 05/04/2007 Aug 28 14:16:24 localhost kernel: task: ffff8801b5825070 ti: ffff8801b58254f0 task.ti: ffff8801b58254f0 Aug 28 14:16:24 localhost kernel: RIP: 0010:[<ffffffff81085eea>] [<ffffffff81085eea>] dazuko_get_value+0x3a/0x130 Aug 28 14:16:24 localhost kernel: RSP: 0018:ffff8801b0301cd8 EFLAGS: 00010286 Aug 28 14:16:24 localhost kernel: RAX: 00000000ffffffff RBX: ffff8801b0301d38 RCX: 0000000000000000 Aug 28 14:16:24 localhost kernel: RDX: ffff8801b0301d38 RSI: 000002dffbcf3b40 RDI: ffffffff81600d47 Aug 28 14:16:24 localhost kernel: RBP: ffffffff81600d47 R08: 000000750ffb3414 R09: 000002dffbcf3a38 Aug 28 14:16:24 localhost kernel: R10: 8000000000000000 R11: 0000000000000293 R12: 000002dffbcf3b40 Aug 28 14:16:24 localhost kernel: R13: ffff880210a62d00 R14: fffffffffffffff2 R15: 0000000000000000 Aug 28 14:16:24 localhost kernel: FS: 000002dffbcf4700(0000) GS:ffff88021fc00000(0000) knlGS:0000000000000000 Aug 28 14:16:24 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Aug 28 14:16:24 localhost kernel: CR2: 000002dffbcf3b40 CR3: 00000000014f6000 CR4: 00000000000007f0 Aug 28 14:16:24 localhost kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Aug 28 14:16:24 localhost kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Aug 28 14:16:24 localhost kernel: Stack: Aug 28 14:16:24 localhost kernel: 0000000000000012 000002dffbcf3b40 0000000000000012 0000000000000012 Aug 28 14:16:24 localhost kernel: ffff880210a62d00 ffffffff810821ad b4dd00d5badbabe5 b4dd00d5badbabe5 Aug 28 14:16:24 localhost kernel: b4dd00d5badbabe5 b4dd00d5badbabe5 b4dd00d5badbabe5 b4dd00d5badbabe5 Aug 28 14:16:24 localhost kernel: Call Trace: Aug 28 14:16:24 localhost kernel: [<ffffffff810821ad>] ? linux_dazuko_device_write+0x12d/0x280 Aug 28 14:16:24 localhost kernel: [<ffffffff81162012>] ? vfs_write+0x152/0x320 Aug 28 14:16:24 localhost kernel: [<ffffffff81162775>] ? SyS_write+0x55/0xb0 Aug 28 14:16:24 localhost kernel: [<ffffffff814eb37f>] ? tracesys+0xe1/0xe6 Aug 28 14:16:24 localhost kernel: Code: 48 83 ec 08 48 85 db 0f 84 ea 00 00 00 4d 85 e4 48 c7 03 00 00 00 00 b8 ff ff ff ff 0f 84 b8 00 00 00 48 85 ed 0f 84 af 00 00 00 <41> 80 3c 24 00 0f 84 a4 00 00 00 0f b6 75 00 40 84 f6 74 38 41 Aug 28 14:16:24 localhost kernel: RIP [<ffffffff81085eea>] dazuko_get_value+0x3a/0x130 Aug 28 14:16:24 localhost kernel: RSP <ffff8801b0301cd8> Aug 28 14:16:24 localhost kernel: CR2: 000002dffbcf3b40 Aug 28 14:16:24 localhost kernel: ---[ end trace d31bcf2dae0758b2 ]---