Re: MLS dominance check behavior on el7
mcstrans mcscolor.c also uses the same logic I'd been using to check dominance so this too will no longer function as expected on el7. Do you any suggestions for doing a 'generic' (one not tied to a specific resource class) dominance check in lieu of context contains? Ted On Mon, Sep 10, 2018 at 1:19 PM Ted Toth wrote: > Understood, thanks. > > On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley > wrote: > >> On 09/10/2018 01:13 PM, Ted Toth wrote: >> > We currently have code running on el6 that does a MLS dominance check >> by >> > calling security_compute_av_raw with the security object class >> > SECCLASS_CONTEXT with permission CONTEXT__CONTAINS as you can see in >> the >> > python code below. When I run this code on el6 s1 dominates s0 however >> > when I run the same code on el7 s1 does not dominate s0. On both >> systems >> > the file read dominance check works as expected. Can anyone help me >> > understand why the context contains check does not work the same on >> both >> > systems? >> >> That would depend entirely on how the constraint is written in the >> policy. I assume this is with the -mls policy on both? seinfo >> --constrain | grep -C1 context would show you the constraint in the >> kernel policy. >> >> Looks like refpolicy defines it as: >> mlsconstrain context contains >> (( h1 dom h2 ) and ( l1 domby l2)); >> >> The 2nd part of the constraint was introduced by: >> commit 4c365f4a6a6f933dd13b0127e03f832c6a6cf8fc >> Author: Harry Ciao >> Date: Tue Feb 15 10:16:32 2011 +0800 >> >> l1 domby l2 for contains MLS constraint >> >> As identified by Stephan Smalley, the current MLS constraint for the >> contains permission of the context class should consider the current >> level of a user along with the clearance level so that mls_systemlow >> is no longer considered contained in mls_systemhigh. >> >> Signed-off-by: Harry Ciao >> >> This was to prevent a user from logging in at a level below their >> authorized range, in the unusual scenario where the user's low level was >> not s0/systemlow. >> >> > >> > Ted >> > >> > >> - >> > >> > import selinux >> > >> > SECCLASS_CONTEXT = selinux.string_to_security_class("context") >> > CONTEXT__CONTAINS = selinux.string_to_av_perm(SECCLASS_CONTEXT, >> "contains") >> > SECCLASS_FILE = selinux.string_to_security_class("file") >> > FILE__READ = selinux.string_to_av_perm(SECCLASS_FILE, "read") >> > >> > raw_con1 = "user_u:user_r:user_t:s1" >> > raw_con2 = "user_u:user_r:user_t:s0" >> > >> > avd = selinux.av_decision() >> > selinux.avc_reset() >> > try: >> > rc = selinux.security_compute_av_raw(raw_con1, raw_con2, >> > SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd) >> > if rc < 0: >> > print("selinux.security_compute_av_raw failed for %s %s" % >> > (raw_con1, raw_con2)) >> > if (avd.allowed & CONTEXT__CONTAINS) == CONTEXT__CONTAINS: >> > print("%s dominates %s" % (raw_con1, raw_con2)) >> > else: >> > print("%s does not dominate %s" % (raw_con1, raw_con2)) >> > except OSError, ex: >> > print "exception calling selinux.security_compute_av_raw", ex >> > >> > avd = selinux.av_decision() >> > selinux.avc_reset() >> > try: >> > rc = selinux.security_compute_av_raw(raw_con1, raw_con2, >> > SECCLASS_FILE, FILE__READ, avd) >> > if rc < 0: >> > print("selinux.security_compute_av_raw failed for %s %s" % >> > (raw_con1, raw_con2)) >> > if (avd.allowed & FILE__READ) == FILE__READ: >> > print("%s dominates %s" % (raw_con1, raw_con2)) >> > else: >> > print("%s does not dominate %s" % (raw_con1, raw_con2)) >> > >> > except OSError: >> > print "exception calling selinux.security_compute_av_raw", ex >> > >> > >> > >> > ___ >> > Selinux mailing list >> > Selinux@tycho.nsa.gov >> > To unsubscribe, send email to selinux-le...@tycho.nsa.gov. >> > To get help, send an email containing "help" to >> selinux-requ...@tycho.nsa.gov. >> > >> >> ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: MLS dominance check behavior on el7
Understood, thanks. On Mon, Sep 10, 2018 at 12:46 PM Stephen Smalley wrote: > On 09/10/2018 01:13 PM, Ted Toth wrote: > > We currently have code running on el6 that does a MLS dominance check by > > calling security_compute_av_raw with the security object class > > SECCLASS_CONTEXT with permission CONTEXT__CONTAINS as you can see in the > > python code below. When I run this code on el6 s1 dominates s0 however > > when I run the same code on el7 s1 does not dominate s0. On both systems > > the file read dominance check works as expected. Can anyone help me > > understand why the context contains check does not work the same on both > > systems? > > That would depend entirely on how the constraint is written in the > policy. I assume this is with the -mls policy on both? seinfo > --constrain | grep -C1 context would show you the constraint in the > kernel policy. > > Looks like refpolicy defines it as: > mlsconstrain context contains > (( h1 dom h2 ) and ( l1 domby l2)); > > The 2nd part of the constraint was introduced by: > commit 4c365f4a6a6f933dd13b0127e03f832c6a6cf8fc > Author: Harry Ciao > Date: Tue Feb 15 10:16:32 2011 +0800 > > l1 domby l2 for contains MLS constraint > > As identified by Stephan Smalley, the current MLS constraint for the > contains permission of the context class should consider the current > level of a user along with the clearance level so that mls_systemlow > is no longer considered contained in mls_systemhigh. > > Signed-off-by: Harry Ciao > > This was to prevent a user from logging in at a level below their > authorized range, in the unusual scenario where the user's low level was > not s0/systemlow. > > > > > Ted > > > > > - > > > > import selinux > > > > SECCLASS_CONTEXT = selinux.string_to_security_class("context") > > CONTEXT__CONTAINS = selinux.string_to_av_perm(SECCLASS_CONTEXT, > "contains") > > SECCLASS_FILE = selinux.string_to_security_class("file") > > FILE__READ = selinux.string_to_av_perm(SECCLASS_FILE, "read") > > > > raw_con1 = "user_u:user_r:user_t:s1" > > raw_con2 = "user_u:user_r:user_t:s0" > > > > avd = selinux.av_decision() > > selinux.avc_reset() > > try: > > rc = selinux.security_compute_av_raw(raw_con1, raw_con2, > > SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd) > > if rc < 0: > > print("selinux.security_compute_av_raw failed for %s %s" % > > (raw_con1, raw_con2)) > > if (avd.allowed & CONTEXT__CONTAINS) == CONTEXT__CONTAINS: > > print("%s dominates %s" % (raw_con1, raw_con2)) > > else: > > print("%s does not dominate %s" % (raw_con1, raw_con2)) > > except OSError, ex: > > print "exception calling selinux.security_compute_av_raw", ex > > > > avd = selinux.av_decision() > > selinux.avc_reset() > > try: > > rc = selinux.security_compute_av_raw(raw_con1, raw_con2, > > SECCLASS_FILE, FILE__READ, avd) > > if rc < 0: > > print("selinux.security_compute_av_raw failed for %s %s" % > > (raw_con1, raw_con2)) > > if (avd.allowed & FILE__READ) == FILE__READ: > > print("%s dominates %s" % (raw_con1, raw_con2)) > > else: > > print("%s does not dominate %s" % (raw_con1, raw_con2)) > > > > except OSError: > > print "exception calling selinux.security_compute_av_raw", ex > > > > > > > > ___ > > Selinux mailing list > > Selinux@tycho.nsa.gov > > To unsubscribe, send email to selinux-le...@tycho.nsa.gov. > > To get help, send an email containing "help" to > selinux-requ...@tycho.nsa.gov. > > > > ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: MLS dominance check behavior on el7
On 09/10/2018 01:13 PM, Ted Toth wrote: We currently have code running on el6 that does a MLS dominance check by calling security_compute_av_raw with the security object class SECCLASS_CONTEXT with permission CONTEXT__CONTAINS as you can see in the python code below. When I run this code on el6 s1 dominates s0 however when I run the same code on el7 s1 does not dominate s0. On both systems the file read dominance check works as expected. Can anyone help me understand why the context contains check does not work the same on both systems? That would depend entirely on how the constraint is written in the policy. I assume this is with the -mls policy on both? seinfo --constrain | grep -C1 context would show you the constraint in the kernel policy. Looks like refpolicy defines it as: mlsconstrain context contains (( h1 dom h2 ) and ( l1 domby l2)); The 2nd part of the constraint was introduced by: commit 4c365f4a6a6f933dd13b0127e03f832c6a6cf8fc Author: Harry Ciao Date: Tue Feb 15 10:16:32 2011 +0800 l1 domby l2 for contains MLS constraint As identified by Stephan Smalley, the current MLS constraint for the contains permission of the context class should consider the current level of a user along with the clearance level so that mls_systemlow is no longer considered contained in mls_systemhigh. Signed-off-by: Harry Ciao This was to prevent a user from logging in at a level below their authorized range, in the unusual scenario where the user's low level was not s0/systemlow. Ted - import selinux SECCLASS_CONTEXT = selinux.string_to_security_class("context") CONTEXT__CONTAINS = selinux.string_to_av_perm(SECCLASS_CONTEXT, "contains") SECCLASS_FILE = selinux.string_to_security_class("file") FILE__READ = selinux.string_to_av_perm(SECCLASS_FILE, "read") raw_con1 = "user_u:user_r:user_t:s1" raw_con2 = "user_u:user_r:user_t:s0" avd = selinux.av_decision() selinux.avc_reset() try: rc = selinux.security_compute_av_raw(raw_con1, raw_con2, SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd) if rc < 0: print("selinux.security_compute_av_raw failed for %s %s" % (raw_con1, raw_con2)) if (avd.allowed & CONTEXT__CONTAINS) == CONTEXT__CONTAINS: print("%s dominates %s" % (raw_con1, raw_con2)) else: print("%s does not dominate %s" % (raw_con1, raw_con2)) except OSError, ex: print "exception calling selinux.security_compute_av_raw", ex avd = selinux.av_decision() selinux.avc_reset() try: rc = selinux.security_compute_av_raw(raw_con1, raw_con2, SECCLASS_FILE, FILE__READ, avd) if rc < 0: print("selinux.security_compute_av_raw failed for %s %s" % (raw_con1, raw_con2)) if (avd.allowed & FILE__READ) == FILE__READ: print("%s dominates %s" % (raw_con1, raw_con2)) else: print("%s does not dominate %s" % (raw_con1, raw_con2)) except OSError: print "exception calling selinux.security_compute_av_raw", ex ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov. ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
MLS dominance check behavior on el7
We currently have code running on el6 that does a MLS dominance check by calling security_compute_av_raw with the security object class SECCLASS_CONTEXT with permission CONTEXT__CONTAINS as you can see in the python code below. When I run this code on el6 s1 dominates s0 however when I run the same code on el7 s1 does not dominate s0. On both systems the file read dominance check works as expected. Can anyone help me understand why the context contains check does not work the same on both systems? Ted - import selinux SECCLASS_CONTEXT = selinux.string_to_security_class("context") CONTEXT__CONTAINS = selinux.string_to_av_perm(SECCLASS_CONTEXT, "contains") SECCLASS_FILE = selinux.string_to_security_class("file") FILE__READ = selinux.string_to_av_perm(SECCLASS_FILE, "read") raw_con1 = "user_u:user_r:user_t:s1" raw_con2 = "user_u:user_r:user_t:s0" avd = selinux.av_decision() selinux.avc_reset() try: rc = selinux.security_compute_av_raw(raw_con1, raw_con2, SECCLASS_CONTEXT, CONTEXT__CONTAINS, avd) if rc < 0: print("selinux.security_compute_av_raw failed for %s %s" % (raw_con1, raw_con2)) if (avd.allowed & CONTEXT__CONTAINS) == CONTEXT__CONTAINS: print("%s dominates %s" % (raw_con1, raw_con2)) else: print("%s does not dominate %s" % (raw_con1, raw_con2)) except OSError, ex: print "exception calling selinux.security_compute_av_raw", ex avd = selinux.av_decision() selinux.avc_reset() try: rc = selinux.security_compute_av_raw(raw_con1, raw_con2, SECCLASS_FILE, FILE__READ, avd) if rc < 0: print("selinux.security_compute_av_raw failed for %s %s" % (raw_con1, raw_con2)) if (avd.allowed & FILE__READ) == FILE__READ: print("%s dominates %s" % (raw_con1, raw_con2)) else: print("%s does not dominate %s" % (raw_con1, raw_con2)) except OSError: print "exception calling selinux.security_compute_av_raw", ex ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Bug report
Hi, ALL There is one bug which has not checking the result value of hashtab_search in the function define_level of policydb_define.c. If the category is not defined, a null-pointer dereference will be taken place. The patch is attached. Best Regards, 李武刚 0001-checkpolicy-check-the-result-value-of-hashtable_sear.patch Description: 0001-checkpolicy-check-the-result-value-of-hashtable_sear.patch ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: WARNING: kmalloc bug in str_read
syzbot has found a reproducer for the following crash on: HEAD commit:a49a9dcce802 Merge tag 'drm-fixes-2018-09-07' of git://ano.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=1198114940 kernel config: https://syzkaller.appspot.com/x/.config?x=6c9564cd177daf0c dashboard link: https://syzkaller.appspot.com/bug?extid=ac488b9811036cea7ea0 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1717dfa940 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13c1adea40 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+ac488b9811036cea7...@syzkaller.appspotmail.com random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) random: sshd: uninitialized urandom read (32 bytes read) audit: type=1400 audit(1536355256.676:7): avc: denied { map } for pid=4365 comm="syz-executor462" path="/root/syz-executor462675731" dev="sda1" ino=16481 scontext=unconfined_u:system_r:insmod_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1 WARNING: CPU: 0 PID: 4365 at mm/slab_common.c:1031 kmalloc_slab+0x56/0x70 mm/slab_common.c:1031 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 4365 Comm: syz-executor462 Not tainted 4.19.0-rc2+ #5 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113 panic+0x238/0x4e7 kernel/panic.c:184 __warn.cold.8+0x163/0x1ba kernel/panic.c:536 report_bug+0x252/0x2d0 lib/bug.c:186 fixup_bug arch/x86/kernel/traps.c:178 [inline] do_error_trap+0x1fc/0x4d0 arch/x86/kernel/traps.c:296 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:316 invalid_op+0x14/0x20 arch/x86/entry/entry_64.S:993 RIP: 0010:kmalloc_slab+0x56/0x70 mm/slab_common.c:1031 Code: c5 40 db f2 87 5d c3 b8 10 00 00 00 48 85 ff 74 f4 83 ef 01 c1 ef 03 0f b6 87 60 da f2 87 eb d8 31 c0 81 e6 00 02 00 00 75 db <0f> 0b 5d c3 48 8b 04 c5 80 da f2 87 5d c3 66 90 66 2e 0f 1f 84 00 RSP: 0018:8801c2317298 EFLAGS: 00010246 RAX: RBX: 0d7fffd6 RCX: 832e9d2e RDX: RSI: RDI: 0d7fffd7 RBP: 8801c2317298 R08: 8801c197a700 R09: ed003b6046de R10: ed003b6046de R11: 8801db0236f3 R12: 006000c0 R13: 8801c2317938 R14: 8801c23173c0 R15: 006000c0 __do_kmalloc mm/slab.c:3713 [inline] __kmalloc+0x25/0x720 mm/slab.c:3727 kmalloc include/linux/slab.h:518 [inline] str_read+0x48/0x160 security/selinux/ss/policydb.c:1104 common_read+0x37c/0x560 security/selinux/ss/policydb.c:1177 policydb_read+0xf09/0x5f90 security/selinux/ss/policydb.c:2407 security_load_policy+0x23b/0x1650 security/selinux/ss/services.c:2165 sel_write_load+0x247/0x460 security/selinux/selinuxfs.c:565 __vfs_write+0x117/0x9d0 fs/read_write.c:485 vfs_write+0x1fc/0x560 fs/read_write.c:549 ksys_write+0x101/0x260 fs/read_write.c:598 __do_sys_write fs/read_write.c:610 [inline] __se_sys_write fs/read_write.c:607 [inline] __x64_sys_write+0x73/0xb0 fs/read_write.c:607 do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x440049 Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00 RSP: 002b:7ffd03e23ca8 EFLAGS: 0213 ORIG_RAX: 0001 RAX: ffda RBX: 004002c8 RCX: 00440049 RDX: 0163 RSI: 2380 RDI: 0003 RBP: 006ca018 R08: R09: 004002c8 R10: R11: 0213 R12: 004018d0 R13: 00401960 R14: R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.