[PATCH ghak47 V1] audit: normalize MAC_POLICY_LOAD record

[Richard Guy Briggs]

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

[Richard Guy Briggs]

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

[Linus Torvalds]

On Mon, Apr 9, 2018 at 11:36 AM, Stephen Smalley  wrote:
> 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

[Stephen Smalley]

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 Handa 
Reported-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.

[jwcart2]

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 Carter 
National Security Agency

Re: CIL namespaces and blockinheritfilter keyword.

[Gary Tierney]

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

[Xin Long]

On Mon, Apr 9, 2018 at 6:44 AM, Richard Haines
 wrote:
> 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

[Xin Long]

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 > .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

[Linus Torvalds]

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.

  Linus

Re: [GIT PULL] SELinux patches for v4.17

[Xin Long]

On Sat, Apr 7, 2018 at 7:07 AM, Linus Torvalds
 wrote:
> 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

[Linus Torvalds]

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.

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.

[Dominick Grift]

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.

[Lukas Vrabec]

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.

[Dominick Grift]

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.

[Dominick Grift]

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