[PATCH ghak47 V1] audit: normalize MAC_POLICY_LOAD record
The audit MAC_POLICY_LOAD record had redundant dangling keywords and was missing information about which LSM was responsible and its completion status. While this record is only issued on success, the parser expects the res= field to be present. Old record: type=MAC_POLICY_LOAD msg=audit(1479299795.404:43): policy loaded auid=0 ses=1 Delete the redundant dangling keywords, add the lsm= field and the res= field. New record: type=MAC_POLICY_LOAD msg=audit(1523293846.204:894): auid=0 ses=1 lsm=selinux res=1 See: https://github.com/linux-audit/audit-kernel/issues/47 Signed-off-by: Richard Guy Briggs--- security/selinux/selinuxfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c index 00b21b2..496915a 100644 --- a/security/selinux/selinuxfs.c +++ b/security/selinux/selinuxfs.c @@ -531,7 +531,7 @@ static ssize_t sel_write_load(struct file *file, const char __user *buf, out1: audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_POLICY_LOAD, - "policy loaded auid=%u ses=%u", + "auid=%u ses=%u lsm=selinux res=1", from_kuid(_user_ns, audit_get_loginuid(current)), audit_get_sessionid(current)); out: -- 1.8.3.1
[PATCH ghak46 V1] audit: normalize MAC_STATUS record
There were two formats of the audit MAC_STATUS record, one of which was more standard than the other. One listed enforcing status changes and the other listed enabled status changes with a non-standard label. In addition, the record was missing information about which LSM was responsible and the operation's completion status. While this record is only issued on success, the parser expects the res= field to be present. old enforcing/permissive: type=MAC_STATUS msg=audit(1523312831.378:24514): enforcing=0 old_enforcing=1 auid=0 ses=1 old enable/disable: type=MAC_STATUS msg=audit(1523312831.378:24514): selinux=0 auid=0 ses=1 List both sets of status and old values and add the lsm= field and the res= field. Here is the new format: type=MAC_STATUS msg=audit(1523293828.657:891): enforcing=0 old_enforcing=1 auid=0 ses=1 enabled=1 old-enabled=1 lsm=selinux res=1 This record already accompanied a SYSCALL record. See: https://github.com/linux-audit/audit-kernel/issues/46 Signed-off-by: Richard Guy Briggs--- security/selinux/selinuxfs.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c index 00eed84..00b21b2 100644 --- a/security/selinux/selinuxfs.c +++ b/security/selinux/selinuxfs.c @@ -145,10 +145,11 @@ static ssize_t sel_write_enforce(struct file *file, const char __user *buf, if (length) goto out; audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_STATUS, - "enforcing=%d old_enforcing=%d auid=%u ses=%u", + "enforcing=%d old_enforcing=%d auid=%u ses=%u" + " enabled=%d old-enabled=%d lsm=selinux res=1", new_value, selinux_enforcing, from_kuid(_user_ns, audit_get_loginuid(current)), - audit_get_sessionid(current)); + audit_get_sessionid(current), selinux_enabled, selinux_enabled); selinux_enforcing = new_value; if (selinux_enforcing) avc_ss_reset(0); @@ -272,9 +273,11 @@ static ssize_t sel_write_disable(struct file *file, const char __user *buf, if (length) goto out; audit_log(current->audit_context, GFP_KERNEL, AUDIT_MAC_STATUS, - "selinux=0 auid=%u ses=%u", + "enforcing=%d old_enforcing=%d auid=%u ses=%u" + " enabled=%d old-enabled=%d lsm=selinux res=1", + selinux_enforcing, selinux_enforcing, from_kuid(_user_ns, audit_get_loginuid(current)), - audit_get_sessionid(current)); + audit_get_sessionid(current), 0, 1); } length = count; -- 1.8.3.1
Re: [PATCH] selinux: fix missing dput() before selinuxfs unmount
On Mon, Apr 9, 2018 at 11:36 AM, Stephen Smalleywrote: > Commit 0619f0f5e36f ("selinux: wrap selinuxfs state") triggers > a BUG when SELinux is runtime-disabled (i.e. systemd or equivalent > disables SELinux before initial policy load via /sys/fs/selinux/disable > based on /etc/selinux/config SELINUX=disabled). Thanks, applied. Linus
[PATCH] selinux: fix missing dput() before selinuxfs unmount
Commit 0619f0f5e36f ("selinux: wrap selinuxfs state") triggers a BUG when SELinux is runtime-disabled (i.e. systemd or equivalent disables SELinux before initial policy load via /sys/fs/selinux/disable based on /etc/selinux/config SELINUX=disabled). This does not manifest if SELinux is disabled via kernel command line argument or if SELinux is enabled (permissive or enforcing). Before: SELinux: Disabled at runtime. BUG: Dentry 6d77e5c7{i=17,n=null} still in use (1) [unmount of selinuxfs selinuxfs] After: SELinux: Disabled at runtime. Fixes: 0619f0f5e36f ("selinux: wrap selinuxfs state") Reported-by: Tetsuo HandaReported-by: Dmitry Vyukov Signed-off-by: Stephen Smalley --- security/selinux/selinuxfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c index 4be683eeba01..245160373dab 100644 --- a/security/selinux/selinuxfs.c +++ b/security/selinux/selinuxfs.c @@ -2061,6 +2061,7 @@ __initcall(init_sel_fs); void exit_sel_fs(void) { sysfs_remove_mount_point(fs_kobj, "selinux"); + dput(selinux_null.dentry); kern_unmount(selinuxfs_mount); unregister_filesystem(_fs_type); } -- 2.14.3
Re: CIL namespaces and blockinheritfilter keyword.
On 04/09/2018 08:07 AM, Dominick Grift wrote: On Mon, Apr 09, 2018 at 01:41:12PM +0200, Lukas Vrabec wrote: On 04/09/2018 10:41 AM, Dominick Grift wrote: On Mon, Apr 09, 2018 at 09:55:23AM +0200, Dominick Grift wrote: On Sun, Apr 08, 2018 at 11:00:53PM +0200, Lukas Vrabec wrote: Hi All, I'm reading "SELINUX COMMON INTERMEDIATE LANGUAGE MOTIVATION AND DESIGN" wiki page [1] and I'm interested in CIL namespaces. I tried several examples related to blockinheritence and all works just great! However, in following example I see keyword "blockinheritfilter": (block logger (blockabstract logger) (type process) (type log) (allow process log (file (getattr append write (block myapp (blockinherit logger) (blockinheritfilter myapp logger (allow process log (file (write) The example above actually demonstrates that you do not need blockinheritfilter (and should not use it for this example), instead you can just append rules to blocks. loggers should not open the log file for write and so the main template should not include that permission in the first place: (block logger (blockabstract logger) (type process) (type log) (allow process log (file (getattr append Then if you have a misbehaving logger you can just append the bad rule to that block: (block badlogger (blockinherit logger) (allow process log (file (write) Or even: (block logger (blockabstract logger) (type process) (type log) (allow process log (file (getattr append (block badlogger (blockabstract badlogger) (blockinherit logger) (allow process log (file (write (block yourlogger (blockinherit badlogger)) Hi Dominick, Yes, This is one of the options to create hierarchy when the block on top will have just minimum rules and every child block will append new rules. Unfortunately, this probably won't work in real world. Let's say that I have this hierarchy and badlogger block contains several allow rules and I want to inherit all of them except one, *BUT* I'm not SELinux policy expert and don't know how hierarchy looks like. That's the reason why I'm looking for blockinheritfilter. I forgot the reason for dropping this functionality (I do recall me asking about this as well in the past but it seems that Google has no record of that) and so I will leave it to others to respond to this part of the question. It was never implemented. Inheritance is done in CIL by copying the inherited rules. This is not complicated in the case where no rules are removed. A different approach would be necessary to allow rules to be removed because we do not normally evaluate things like attributes and attribute sets until after all of the copying is done. We would have to evaluate as much of the policy as we could and then keep cycling through all of the inheritance rules evaluating what we could with each pass until we had evaluated all of the rules. This is why we punted and decided to leave things like removing rules to a higher-level language. However, we should go via creating block namespaces hierarchy as you described if there are no plans to implement this feature. Sorry, but there are currently no plans to implement this feature. Jim Thanks, Lukas. Appending instead of filtering probably just the better approach also if you consider that blocks might have macros or nested blocks You probably would not be able to filter any of those. If I understand it correctly, it should "remove" rule: allow myapp.process log:file write; So process type in myapp should have allowed: allow myapp.process log:file {getattr append}; And process type in logger should have allowed: allow logger.process log:file {getattr append write}; Which could be very cool feature, but I don't see any code in secilc related to "blockinheritfilter". Are there any plans to implement also this in CIL namespaces or is there any other way how to handle this (DELETE statement is also not implemented) ? Thanks for any help. Lukas. [1] https://github.com/SELinuxProject/cil/wiki -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. -- James CarterNational Security Agency
Re: CIL namespaces and blockinheritfilter keyword.
On Mon, Apr 09, 2018 at 01:41:12PM +0200, Lukas Vrabec wrote: ... snip ... Those wiki pages on SELinuxProject/cil are now pretty out of date (you'll notice that some other statements mentioned there like `template` are not implemented as well). The updated documentation is at https://github.com/SELinuxProject/selinux/tree/master/secilc/docs. Hi Dominick, Yes, This is one of the options to create hierarchy when the block on top will have just minimum rules and every child block will append new rules. Unfortunately, this probably won't work in real world. Let's say that I have this hierarchy and badlogger block contains several allow rules and I want to inherit all of them except one, *BUT* I'm not SELinux policy expert and don't know how hierarchy looks like. That's the reason why I'm looking for blockinheritfilter. I think it's more reasonable for someone not intimate with the policy to familiarize themselves with the hierarchy/composition of a well structured policy, rather than what they may need to disallow in a given scope (which may come from other inherited blocks, calls to macros, or `in` statements scattered across several policy modules). This means they can compose their policy out of high level building blocks rather than low level allow rules (which arguably would require a policy expert to fully understand the implications of). "blockinheritfilter" also seems to be at odds with the permission whitelisting/deny-by-default model of SELinux by having the policy author revoke permissions rather than permit them. Thanks, Gary. However, we should go via creating block namespaces hierarchy as you described if there are no plans to implement this feature. Thanks, Lukas. -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc.
Re: [GIT PULL] SELinux patches for v4.17
On Mon, Apr 9, 2018 at 6:44 AM, Richard Haineswrote: > On Sun, 2018-04-08 at 19:59 +0100, Richard Haines via Selinux wrote: >> On Mon, 2018-04-09 at 01:43 +0800, Xin Long wrote: >> > On Sun, Apr 8, 2018 at 10:09 PM, Richard Haines >> > wrote: >> > > On Sun, 2018-04-08 at 08:50 -0400, Paul Moore wrote: >> > > > On April 7, 2018 1:03:57 PM Linus Torvalds > > > > da >> > > > tion >> > > > .org> wrote: >> > > > On Sat, Apr 7, 2018 at 9:54 AM, Richard Haines >> > > > wrote: >> > > > >> > > > So please check my resolution, but also somebody should tell me >> > > > "Linus, you're a cretin, sctp_connect() doesn't want that >> > > > security_sctp_bind_connect() at all because it was already done >> > > > by >> > > > XYZ" >> > > > >> > > > sctp_connect() or __sctp_connect() do not need to call >> > > > security_sctp_bind_connect(). This is because the connect(2) >> > > > call >> > > > will >> > > > handle the checks required via security_socket_connect(): >> > > > >> > > > Ok, thanks, that's exactly what I wanted to get. >> > > > >> > > > Anyway, somebody should still verify that it all looks good in >> > > > my >> > > > tree, but I don't actually expect the merge to have had any >> > > > issues >> > > > even if the refactoring made it a bit more complex than most >> > > > merges >> > > > are. >> > > > >> > > > Thanks for the quick response Richard. >> > > > >> > > > Xin Long looked it over and gave it the thumbs up, I'll take a >> > > > look >> > > > too, but to be honest I trust his SCTP understanding much more >> > > > than >> > > > mine. I also do weekly tests of each rcX release at a minimum >> > > > so >> > > > if >> > > > something odd pops up I'll make sure you get a fix. >> > > > >> > > > Thanks again everyone. >> > > >> > > I built the kernel this morning and sorry to spoil the party, but >> > > I've >> > > run into a problem with lksctp-tools when running the func_tests: >> > > >> > > make v6test >> > > .. >> > > .. >> > > ./test_timetolive_v6 >> > > test_timetolive.c 0 INFO : Creating fillmsg of size 3087 >> > > test_timetolive.c 1 PASS : Send a message with timeout >> > > test_timetolive.c 2 PASS : Send a message with no timeout >> > > test_timetolive.c 3 PASS : Send a fragmented message with >> > > timeout >> > > test_timetolive.c 0 INFO : ** SLEEPING for 3 seconds ** >> > > test_timetolive.c 4 BROK : Got a datamsg of unexpected >> > > length:23, >> > > expected length:27 >> > > DUMP_CORE sctputil.c: 247 >> > > /bin/sh: line 1: 30981 Segmentation fault (core dumped) ./$a >> > > test_timetolive_v6 fails >> > > >> > > make v4 test fails the same way. I'm using lksctp-tools from [1]. >> > > I >> > > have not investigated the cause yet as just found this and >> > > thought >> > > I >> > > should flag first just in case someone has the answer !!! >> > >> > test_timetolive(_v6) works for me, In lksctp-tools/src/func_tests, >> > I >> > had >> > another case failed,./test_1_to_1_events, it's caused by: >> > commit 30f6ebf65bc46161c5aaff1db2e6e7c76aa4a06b >> > Author: Xin Long >> > Date: Wed Mar 14 19:05:34 2018 +0800 >> > >> > sctp: add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT >> > >> > It's not kernel's issue, after that commit, ./test_1_to_1_events >> > should >> > have been improved. or avoid it by 'sysctl -w >> > net.sctp.auth_enable=1' >> > >> > I'm not sure why test_timetolive(_v6) is not working in your env. >> >> It appears to depend on the run sequence of the tests. I rebooted the >> system, ran test_timetolive_v6, it worked okay. >> Ran "sctp-tests run" on a terminal, then ran test_timetolive_v6 at >> various intervals on another terminal. Once sctp-tests started the >> "=== >> ndatasched ===" sequence, test_timetolive_v6 failed. > > 1) When SCTP is initialised /proc/sys/net/sctp/prsctp_enable = 1 > 2) When sctp-tests/testcase/regression/extoverflow/test.sh is executed, > on exit it sets prsctp_enable = 0. This seems to be causing the issue > I'm seeing. I can now simulate the problem: > > Running from fresh boot: > checksctp > cat /proc/sys/net/sctp/prsctp_enable > 1 > ./test_timetolive_v6 > passes > echo 0 > /proc/sys/net/sctp/prsctp_enable > ./test_timetolive_v6 > fails > echo 1 > /proc/sys/net/sctp/prsctp_enable > ./test_timetolive_v6 > passes I see ... commit 8ae808eb853e3789b81b8a502cdf22bb01b76880 Author: Xin Long Date: Sat Oct 8 11:40:16 2016 +0800 sctp: remove the old ttl expires policy ttl expire is considered as one of the prsctp policies after this commit, so prsctp_enable is required. I will think to update this test case in lksctp-tools. Thanks for the reproducer.
Re: [GIT PULL] SELinux patches for v4.17
On Sun, Apr 8, 2018 at 10:09 PM, Richard Haineswrote: > On Sun, 2018-04-08 at 08:50 -0400, Paul Moore wrote: >> On April 7, 2018 1:03:57 PM Linus Torvalds > .org> wrote: >> On Sat, Apr 7, 2018 at 9:54 AM, Richard Haines >> wrote: >> >> So please check my resolution, but also somebody should tell me >> "Linus, you're a cretin, sctp_connect() doesn't want that >> security_sctp_bind_connect() at all because it was already done by >> XYZ" >> >> sctp_connect() or __sctp_connect() do not need to call >> security_sctp_bind_connect(). This is because the connect(2) call >> will >> handle the checks required via security_socket_connect(): >> >> Ok, thanks, that's exactly what I wanted to get. >> >> Anyway, somebody should still verify that it all looks good in my >> tree, but I don't actually expect the merge to have had any issues >> even if the refactoring made it a bit more complex than most merges >> are. >> >> Thanks for the quick response Richard. >> >> Xin Long looked it over and gave it the thumbs up, I'll take a look >> too, but to be honest I trust his SCTP understanding much more than >> mine. I also do weekly tests of each rcX release at a minimum so if >> something odd pops up I'll make sure you get a fix. >> >> Thanks again everyone. > > I built the kernel this morning and sorry to spoil the party, but I've > run into a problem with lksctp-tools when running the func_tests: > > make v6test > .. > .. > ./test_timetolive_v6 > test_timetolive.c 0 INFO : Creating fillmsg of size 3087 > test_timetolive.c 1 PASS : Send a message with timeout > test_timetolive.c 2 PASS : Send a message with no timeout > test_timetolive.c 3 PASS : Send a fragmented message with timeout > test_timetolive.c 0 INFO : ** SLEEPING for 3 seconds ** > test_timetolive.c 4 BROK : Got a datamsg of unexpected length:23, > expected length:27 > DUMP_CORE sctputil.c: 247 > /bin/sh: line 1: 30981 Segmentation fault (core dumped) ./$a > test_timetolive_v6 fails > > make v4 test fails the same way. I'm using lksctp-tools from [1]. I > have not investigated the cause yet as just found this and thought I > should flag first just in case someone has the answer !!! test_timetolive(_v6) works for me, In lksctp-tools/src/func_tests, I had another case failed,./test_1_to_1_events, it's caused by: commit 30f6ebf65bc46161c5aaff1db2e6e7c76aa4a06b Author: Xin Long Date: Wed Mar 14 19:05:34 2018 +0800 sctp: add SCTP_AUTH_NO_AUTH type for AUTHENTICATION_EVENT It's not kernel's issue, after that commit, ./test_1_to_1_events should have been improved. or avoid it by 'sysctl -w net.sctp.auth_enable=1' I'm not sure why test_timetolive(_v6) is not working in your env. > > On the bright side, I've run the sctp-tests from [2] with no problems > and also the selinux-testsuite with my SCTP patch from [3] using an > updated Fedora policy from [4] (with sctp support added), all in > enforcing mode. > > Also the LTP test passed: > cd /opt/ltp/ > cat runtest/syscalls |grep connect01>runtest/connect-syscall > ./runltp -pq -f connect-syscall > > > [1] https://github.com/sctp/lksctp-tools > [2] https://github.com/sctp/sctp-tests > [3] https://marc.info/?l=selinux=152156947715709=2 > [4] https://github.com/fedora-selinux/selinux-policy > > >> >> -- >> paul moore >> www.paul-moore.com >> >> >>
Re: [GIT PULL] SELinux patches for v4.17
On Sat, Apr 7, 2018 at 9:54 AM, Richard Haineswrote: >> >> So please check my resolution, but also somebody should tell me >> "Linus, you're a cretin, sctp_connect() doesn't want that >> security_sctp_bind_connect() at all because it was already done by >> XYZ" > > sctp_connect() or __sctp_connect() do not need to call > security_sctp_bind_connect(). This is because the connect(2) call will > handle the checks required via security_socket_connect(): Ok, thanks, that's exactly what I wanted to get. Anyway, somebody should still verify that it all looks good in my tree, but I don't actually expect the merge to have had any issues even if the refactoring made it a bit more complex than most merges are. Linus
Re: [GIT PULL] SELinux patches for v4.17
On Sat, Apr 7, 2018 at 7:07 AM, Linus Torvaldswrote: > On Tue, Apr 3, 2018 at 6:37 PM, Paul Moore wrote: >> >> Everything passes the selinux-testsuite, but there are a few known >> merge conflicts. The first is with the netdev tree and is in >> net/sctp/socket.c. Unfortunately it is a bit ugly, thankfully Stephen >> Rothwell has already done the heavy lifting in resolving the merge for >> you, and the SCTP folks have given his merge patch a thumbs-up. > > I ended up re-doing the merge, and it looks like some more sctp > changes happened after Stephen's merge anyway, so mine didn't end up > quite like his. > You're right, a sctp fix went into net-next after Stephen's that merge. https://patchwork.ozlabs.org/patch/884469/ (v1) https://patchwork.ozlabs.org/patch/884971/ (v2) Which caused the resolution to have changed again. I've checked the new resolution on your tree, the SCTP part is all good. Thanks.
Re: [GIT PULL] SELinux patches for v4.17
On Tue, Apr 3, 2018 at 6:37 PM, Paul Moorewrote: > > Everything passes the selinux-testsuite, but there are a few known > merge conflicts. The first is with the netdev tree and is in > net/sctp/socket.c. Unfortunately it is a bit ugly, thankfully Stephen > Rothwell has already done the heavy lifting in resolving the merge for > you, and the SCTP folks have given his merge patch a thumbs-up. I ended up re-doing the merge, and it looks like some more sctp changes happened after Stephen's merge anyway, so mine didn't end up quite like his. Adding Xin Long to see if he can verify it again, but it all *looks* sane. While looking at it, it struck me that the new security hooks don't seem to hook into __sctp_connect(), which also does that scope = sctp_scope(); asoc = sctp_association_new(ep, sk, scope, GFP_KERNEL); thing. Is that intentional? The sendmsg case does that security_sctp_bind_connect, the actual __sctp_connect() does not. This is not because I screwed up the merge - it's that way in the SELinux tree too. And I obviously _left_ it that way, but while doing the merge and trying to understand what was going on, this struck me. I'm probably missing something really obvious why the connect case doesn't want to do it thgere. NOTE! I do see it being done in __sctp_setsockopt_connectx(). But __sctp_connect() has another caller (in sctp_connect()) which doesn't have that security_sctp_bind_connect() call. So please check my resolution, but also somebody should tell me "Linus, you're a cretin, sctp_connect() doesn't want that security_sctp_bind_connect() at all because it was already done by XYZ" Linus
Re: CIL namespaces and blockinheritfilter keyword.
On Mon, Apr 09, 2018 at 01:41:12PM +0200, Lukas Vrabec wrote: > On 04/09/2018 10:41 AM, Dominick Grift wrote: > > On Mon, Apr 09, 2018 at 09:55:23AM +0200, Dominick Grift wrote: > >> On Sun, Apr 08, 2018 at 11:00:53PM +0200, Lukas Vrabec wrote: > >>> Hi All, > >>> > >>> I'm reading "SELINUX COMMON INTERMEDIATE LANGUAGE MOTIVATION AND DESIGN" > >>> wiki page [1] and I'm interested in CIL namespaces. I tried several > >>> examples related to blockinheritence and all works just great! > >>> > >>> However, in following example I see keyword "blockinheritfilter": > >>> > >>> (block logger > >>> (blockabstract logger) > >>> (type process) > >>> (type log) > >>> (allow process log (file (getattr append write > >>> > >>> (block myapp > >>> (blockinherit logger) > >>> (blockinheritfilter myapp logger > >>> (allow process log (file (write) > >>> > >> > >> The example above actually demonstrates that you do not need > >> blockinheritfilter (and should not use it for this example), instead you > >> can just append rules to blocks. > >> > >> loggers should not open the log file for write and so the main template > >> should not include that permission in the first place: > >> > >> (block logger > >>(blockabstract logger) > >>(type process) > >>(type log) > >>(allow process log (file (getattr append > >> > >> Then if you have a misbehaving logger you can just append the bad rule to > >> that block: > >> > >> (block badlogger > >>(blockinherit logger) > >>(allow process log (file (write) > > > > Or even: > > > > (block logger > >(blockabstract logger) > >(type process) > >(type log) > >(allow process log (file (getattr append > > > > (block badlogger > >(blockabstract badlogger) > >(blockinherit logger) > >(allow process log (file (write > > > > (block yourlogger > >(blockinherit badlogger)) > > > > Hi Dominick, > > Yes, This is one of the options to create hierarchy when the block on > top will have just minimum rules and every child block will append new > rules. > > Unfortunately, this probably won't work in real world. Let's say that I > have this hierarchy and badlogger block contains several allow rules and > I want to inherit all of them except one, *BUT* I'm not SELinux policy > expert and don't know how hierarchy looks like. That's the reason why > I'm looking for blockinheritfilter. I forgot the reason for dropping this functionality (I do recall me asking about this as well in the past but it seems that Google has no record of that) and so I will leave it to others to respond to this part of the question. > > However, we should go via creating block namespaces hierarchy as you > described if there are no plans to implement this feature. > > Thanks, > Lukas. > > >> > >> Appending instead of filtering probably just the better approach also if > >> you consider that blocks might have macros or nested blocks > >> You probably would not be able to filter any of those. > >> > >> > >>> > >>> If I understand it correctly, it should "remove" rule: > >>> allow myapp.process log:file write; > >>> > >>> So process type in myapp should have allowed: > >>> allow myapp.process log:file {getattr append}; > >>> > >>> And process type in logger should have allowed: > >>> allow logger.process log:file {getattr append write}; > >>> > >>> Which could be very cool feature, but I don't see any code in secilc > >>> related to "blockinheritfilter". Are there any plans to implement also > >>> this in CIL namespaces or is there any other way how to handle this > >>> (DELETE statement is also not implemented) ? > >>> > >>> Thanks for any help. > >>> Lukas. > >>> > >>> > >>> [1] https://github.com/SELinuxProject/cil/wiki > >>> > >>> -- > >>> Lukas Vrabec > >>> Software Engineer, Security Technologies > >>> Red Hat, Inc. > >>> > >> > >> > >> > >> > >> -- > >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > >> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > >> Dominick Grift > > > > > > > > > -- > Lukas Vrabec > Software Engineer, Security Technologies > Red Hat, Inc. > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: CIL namespaces and blockinheritfilter keyword.
On 04/09/2018 10:41 AM, Dominick Grift wrote: > On Mon, Apr 09, 2018 at 09:55:23AM +0200, Dominick Grift wrote: >> On Sun, Apr 08, 2018 at 11:00:53PM +0200, Lukas Vrabec wrote: >>> Hi All, >>> >>> I'm reading "SELINUX COMMON INTERMEDIATE LANGUAGE MOTIVATION AND DESIGN" >>> wiki page [1] and I'm interested in CIL namespaces. I tried several >>> examples related to blockinheritence and all works just great! >>> >>> However, in following example I see keyword "blockinheritfilter": >>> >>> (block logger >>> (blockabstract logger) >>> (type process) >>> (type log) >>> (allow process log (file (getattr append write >>> >>> (block myapp >>> (blockinherit logger) >>> (blockinheritfilter myapp logger >>> (allow process log (file (write) >>> >> >> The example above actually demonstrates that you do not need >> blockinheritfilter (and should not use it for this example), instead you can >> just append rules to blocks. >> >> loggers should not open the log file for write and so the main template >> should not include that permission in the first place: >> >> (block logger >>(blockabstract logger) >>(type process) >>(type log) >>(allow process log (file (getattr append >> >> Then if you have a misbehaving logger you can just append the bad rule to >> that block: >> >> (block badlogger >>(blockinherit logger) >>(allow process log (file (write) > > Or even: > > (block logger >(blockabstract logger) >(type process) >(type log) >(allow process log (file (getattr append > > (block badlogger >(blockabstract badlogger) >(blockinherit logger) >(allow process log (file (write > > (block yourlogger >(blockinherit badlogger)) > Hi Dominick, Yes, This is one of the options to create hierarchy when the block on top will have just minimum rules and every child block will append new rules. Unfortunately, this probably won't work in real world. Let's say that I have this hierarchy and badlogger block contains several allow rules and I want to inherit all of them except one, *BUT* I'm not SELinux policy expert and don't know how hierarchy looks like. That's the reason why I'm looking for blockinheritfilter. However, we should go via creating block namespaces hierarchy as you described if there are no plans to implement this feature. Thanks, Lukas. >> >> Appending instead of filtering probably just the better approach also if you >> consider that blocks might have macros or nested blocks >> You probably would not be able to filter any of those. >> >> >>> >>> If I understand it correctly, it should "remove" rule: >>> allow myapp.process log:file write; >>> >>> So process type in myapp should have allowed: >>> allow myapp.process log:file {getattr append}; >>> >>> And process type in logger should have allowed: >>> allow logger.process log:file {getattr append write}; >>> >>> Which could be very cool feature, but I don't see any code in secilc >>> related to "blockinheritfilter". Are there any plans to implement also >>> this in CIL namespaces or is there any other way how to handle this >>> (DELETE statement is also not implemented) ? >>> >>> Thanks for any help. >>> Lukas. >>> >>> >>> [1] https://github.com/SELinuxProject/cil/wiki >>> >>> -- >>> Lukas Vrabec >>> Software Engineer, Security Technologies >>> Red Hat, Inc. >>> >> >> >> >> >> -- >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 >> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 >> Dominick Grift > > > -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. signature.asc Description: OpenPGP digital signature
Re: CIL namespaces and blockinheritfilter keyword.
On Mon, Apr 09, 2018 at 09:55:23AM +0200, Dominick Grift wrote: > On Sun, Apr 08, 2018 at 11:00:53PM +0200, Lukas Vrabec wrote: > > Hi All, > > > > I'm reading "SELINUX COMMON INTERMEDIATE LANGUAGE MOTIVATION AND DESIGN" > > wiki page [1] and I'm interested in CIL namespaces. I tried several > > examples related to blockinheritence and all works just great! > > > > However, in following example I see keyword "blockinheritfilter": > > > > (block logger > > (blockabstract logger) > > (type process) > > (type log) > > (allow process log (file (getattr append write > > > > (block myapp > > (blockinherit logger) > > (blockinheritfilter myapp logger > > (allow process log (file (write) > > > > The example above actually demonstrates that you do not need > blockinheritfilter (and should not use it for this example), instead you can > just append rules to blocks. > > loggers should not open the log file for write and so the main template > should not include that permission in the first place: > > (block logger >(blockabstract logger) >(type process) >(type log) >(allow process log (file (getattr append > > Then if you have a misbehaving logger you can just append the bad rule to > that block: > > (block badlogger >(blockinherit logger) >(allow process log (file (write) Or even: (block logger (blockabstract logger) (type process) (type log) (allow process log (file (getattr append (block badlogger (blockabstract badlogger) (blockinherit logger) (allow process log (file (write (block yourlogger (blockinherit badlogger)) > > Appending instead of filtering probably just the better approach also if you > consider that blocks might have macros or nested blocks > You probably would not be able to filter any of those. > > > > > > If I understand it correctly, it should "remove" rule: > > allow myapp.process log:file write; > > > > So process type in myapp should have allowed: > > allow myapp.process log:file {getattr append}; > > > > And process type in logger should have allowed: > > allow logger.process log:file {getattr append write}; > > > > Which could be very cool feature, but I don't see any code in secilc > > related to "blockinheritfilter". Are there any plans to implement also > > this in CIL namespaces or is there any other way how to handle this > > (DELETE statement is also not implemented) ? > > > > Thanks for any help. > > Lukas. > > > > > > [1] https://github.com/SELinuxProject/cil/wiki > > > > -- > > Lukas Vrabec > > Software Engineer, Security Technologies > > Red Hat, Inc. > > > > > > > -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > Dominick Grift -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: CIL namespaces and blockinheritfilter keyword.
On Sun, Apr 08, 2018 at 11:00:53PM +0200, Lukas Vrabec wrote: > Hi All, > > I'm reading "SELINUX COMMON INTERMEDIATE LANGUAGE MOTIVATION AND DESIGN" > wiki page [1] and I'm interested in CIL namespaces. I tried several > examples related to blockinheritence and all works just great! > > However, in following example I see keyword "blockinheritfilter": > > (block logger > (blockabstract logger) > (type process) > (type log) > (allow process log (file (getattr append write > > (block myapp > (blockinherit logger) > (blockinheritfilter myapp logger > (allow process log (file (write) > The example above actually demonstrates that you do not need blockinheritfilter (and should not use it for this example), instead you can just append rules to blocks. loggers should not open the log file for write and so the main template should not include that permission in the first place: (block logger (blockabstract logger) (type process) (type log) (allow process log (file (getattr append Then if you have a misbehaving logger you can just append the bad rule to that block: (block badlogger (blockinherit logger) (allow process log (file (write) Appending instead of filtering probably just the better approach also if you consider that blocks might have macros or nested blocks You probably would not be able to filter any of those. > > If I understand it correctly, it should "remove" rule: > allow myapp.process log:file write; > > So process type in myapp should have allowed: > allow myapp.process log:file {getattr append}; > > And process type in logger should have allowed: > allow logger.process log:file {getattr append write}; > > Which could be very cool feature, but I don't see any code in secilc > related to "blockinheritfilter". Are there any plans to implement also > this in CIL namespaces or is there any other way how to handle this > (DELETE statement is also not implemented) ? > > Thanks for any help. > Lukas. > > > [1] https://github.com/SELinuxProject/cil/wiki > > -- > Lukas Vrabec > Software Engineer, Security Technologies > Red Hat, Inc. > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature