Hello,
I am not sure this use case has come up before but some our systems are set permissive. I have 3 files I want to have shared with 644 on purpose. The goal is for selinux to allow users(permissive) to read the file but I need a context that will still report an AVC to audit.log as that will be forwarded to a SIEM where rules will be in place to contact security. I have tried auditd_etc_t, var_log_t but nothing ever shows up in audit.log when watching a user cat/vi the files.
In this situation I actually want to see denials lol but not 100% I am seeing this right. Any help is appreciated.
-rw-r--r--. root root unconfined_u:object_r:auditd_etc_t:s0 fil1.pgp -rw-r--r--. root root unconfined_u:object_r:auditd_etc_t:s0 file2.docx -rw-r--r--. root root unconfined_u:object_r:var_log_t:s0 file3.docx
Sean Hogan
On Wed, Jun 27, 2018 at 11:00 PM, Sean Hogan schogan@us.ibm.com wrote:
Hello,
I am not sure this use case has come up before but some our systems are set permissive. I have 3 files I want to have shared with 644 on purpose. The goal is for selinux to allow users(permissive) to read the file but I need a context that will still report an AVC to audit.log as that will be forwarded to a SIEM where rules will be in place to contact security. I have tried auditd_etc_t, var_log_t but nothing ever shows up in audit.log when watching a user cat/vi the files.
In this situation I actually want to see denials lol but not 100% I am seeing this right. Any help is appreciated.
-rw-r--r--. root root unconfined_u:object_r:auditd_etc_t:s0 fil1.pgp -rw-r--r--. root root unconfined_u:object_r:auditd_etc_t:s0 file2.docx -rw-r--r--. root root unconfined_u:object_r:var_log_t:s0 file3.docx
Hello,
Do you mean access from a user console/shell? SELinux only pays attention to labels, so it would not be easy to achieve this goal. Can you describe the use case? Maybe you just need to use audit watch rules:
# auditctl -w /path/file1 -p r -k secure-access
which will subsequently audit each read access as
type=SYSCALL msg=audit(1530272932.863:1867): arch=c000003e syscall=2 success=yes exit=3 a0=7ffcfb5e6706 a1=0 a2=1fffffffffff0000 a3=7ffcfb5e5730 items=1 ppid=10516 pid=11699 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=224 comm="cat" exe="/usr/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="secure-access" type=CWD msg=audit(1530272932.863:1867): cwd="/cwd" type=PATH msg=audit(1530272932.863:1867): item=0 name="/path/file1" inode=6508 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=PROCTITLE msg=audit(1530272932.863:1867): proctitle=636174002F706174682F66696C6531
Hi Zdenek,
Thanks for the reply. Yes sir.. so anytime a user tries to access any of the 3 files we would want something unique to key in on in the logs to identify them. We would then push those logs to a SIEM to auto generate offenses which auto generates call outs.
I guess I was making it more complicated than needed by going the SE route. I will give the audit rule mod a shot to see how it turns out and let you know.
Thanks
Sean Hogan
From: Zdenek Pytela zpytela@redhat.com To: Sean Hogan schogan@us.ibm.com Cc: selinux@lists.fedoraproject.org Date: 06/29/2018 04:51 AM Subject: Re: Logging Denials
On Wed, Jun 27, 2018 at 11:00 PM, Sean Hogan schogan@us.ibm.com wrote: Hello,
I am not sure this use case has come up before but some our systems are set permissive. I have 3 files I want to have shared with 644 on purpose. The goal is for selinux to allow users(permissive) to read the file but I need a context that will still report an AVC to audit.log as that will be forwarded to a SIEM where rules will be in place to contact security. I have tried auditd_etc_t, var_log_t but nothing ever shows up in audit.log when watching a user cat/vi the files.
In this situation I actually want to see denials lol but not 100% I am seeing this right. Any help is appreciated.
-rw-r--r--. root root unconfined_u:object_r:auditd_etc_t:s0 fil1.pgp -rw-r--r--. root root unconfined_u:object_r:auditd_etc_t:s0 file2.docx -rw-r--r--. root root unconfined_u:object_r:var_log_t:s0 file3.docx
Hello,
Do you mean access from a user console/shell? SELinux only pays attention to labels, so it would not be easy to achieve this goal. Can you describe the use case? Maybe you just need to use audit watch rules:
# auditctl -w /path/file1 -p r -k secure-access
which will subsequently audit each read access as
type=SYSCALL msg=audit(1530272932.863:1867): arch=c000003e syscall=2 success=yes exit=3 a0=7ffcfb5e6706 a1=0 a2=1fffffffffff0000 a3=7ffcfb5e5730 items=1 ppid=10516 pid=11699 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=224 comm="cat" exe="/usr/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="secure-access" type=CWD msg=audit(1530272932.863:1867): cwd="/cwd" type=PATH msg=audit(1530272932.863:1867): item=0 name="/path/file1" inode=6508 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=PROCTITLE msg=audit(1530272932.863:1867): proctitle=636174002F706174682F66696C6531
--
Zdenek Pytela, Senior technical support engineer and team lead Customer Engagement and Experience, Red Hat Czech E-mail: zpytela@redhat.com, IRC: zpytela _______________________________________________ selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or...
On 06/29/2018 07:00 PM, Sean Hogan wrote:
Hi Zdenek,
Thanks for the reply. Yes sir.. so anytime a user tries to access any of the 3 files we would want something unique to key in on in the logs to identify them. We would then push those logs to a SIEM to auto generate offenses which auto generates call outs.
I guess I was making it more complicated than needed by going the SE route. I will give the audit rule mod a shot to see how it turns out and let you know.
Hi,
I'm not suer if I understand your question, but auditallow is what you're looking for: https://selinuxproject.org/page/AVCRules
(search for auditallow rule type)
Thanks, Lukas.
Thanks
Sean Hogan
Inactive hide details for Zdenek Pytela ---06/29/2018 04:51:41 AM---On Wed, Jun 27, 2018 at 11:00 PM, Sean Hogan <schogan@us.ibZdenek Pytela ---06/29/2018 04:51:41 AM---On Wed, Jun 27, 2018 at 11:00 PM, Sean Hogan schogan@us.ibm.com wrote: > Hello,
From: Zdenek Pytela zpytela@redhat.com To: Sean Hogan schogan@us.ibm.com Cc: selinux@lists.fedoraproject.org Date: 06/29/2018 04:51 AM Subject: Re: Logging Denials
On Wed, Jun 27, 2018 at 11:00 PM, Sean Hogan <_schogan@us.ibm.com_ mailto:schogan@us.ibm.com> wrote:
Hello, I am not sure this use case has come up before but some our systems are set permissive. I have 3 files I want to have shared with 644 on purpose. The goal is for selinux to allow users(permissive) to read the file but I need a context that will still report an AVC to audit.log as that will be forwarded to a SIEM where rules will be in place to contact security. I have tried auditd_etc_t, var_log_t but nothing ever shows up in audit.log when watching a user cat/vi the files. In this situation I actually want to see denials lol but not 100% I am seeing this right. Any help is appreciated. -rw-r--r--. root root unconfined_u:object_r:auditd_etc_t:s0 fil1.pgp -rw-r--r--. root root unconfined_u:object_r:auditd_etc_t:s0 file2.docx -rw-r--r--. root root unconfined_u:object_r:var_log_t:s0 file3.docx
Hello,
Do you mean access from a user console/shell? SELinux only pays attention to labels, so it would not be easy to achieve this goal. Can you describe the use case? Maybe you just need to use audit watch rules:
# auditctl -w /path/file1 -p r -k secure-access
which will subsequently audit each read access as
type=SYSCALL msg=audit(1530272932.863:1867): arch=c000003e syscall=2 success=yes exit=3 a0=7ffcfb5e6706 a1=0 a2=1fffffffffff0000 a3=7ffcfb5e5730 items=1 ppid=10516 pid=11699 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=224 comm="cat" exe="/usr/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="secure-access" type=CWD msg=audit(1530272932.863:1867): cwd="/cwd" type=PATH msg=audit(1530272932.863:1867): item=0 name="/path/file1" inode=6508 dev=fd:00 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:default_t:s0 objtype=NORMAL cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0 type=PROCTITLE msg=audit(1530272932.863:1867): proctitle=636174002F706174682F66696C6531
--
Zdenek Pytela, Senior technical support engineer and team lead Customer Engagement and Experience, Red Hat Czech E-mail: _zpytela@redhat.com_ mailto:zpytela@redhat.com, IRC: zpytela_______________________________________________ selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or...
selinux mailing list -- selinux@lists.fedoraproject.org To unsubscribe send an email to selinux-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/selinux@lists.fedoraproject.or...
selinux@lists.fedoraproject.org