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
Zdenek Pytela ---06/29/2018 04:51:41 AM---On Wed, Jun 27, 2018 at 11:00 PM, Sean Hogan <schogan@xxxxxxxxxx> wrote: > Hello,From: Zdenek Pytela <zpytela@xxxxxxxxxx>
To: Sean Hogan <schogan@xxxxxxxxxx>
Cc: selinux@xxxxxxxxxxxxxxxxxxxxxxx
Date: 06/29/2018 04:51 AM
Subject: Re: Logging Denials
On Wed, Jun 27, 2018 at 11:00 PM, Sean Hogan <schogan@xxxxxxxxxx> 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@xxxxxxxxxx, IRC: zpytela_______________________________________________
selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx/message/YBFNEXSCEJP4A26K3YLRHITINR5IIZXL/
_______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx/message/YDKIRKJBNVUCM7FNU2O6IQTIV55RVVDZ/
