On 05/16/2018 01:25 PM, m.roth@xxxxxxxxx wrote: > Ok, what's the "correct" way to deal with systems developed in-house, that > have their own sets up subdirectories. By "systems developed in-house", do you mean application software that you are developing? And if so, do you mean something that runs as a service/daemon or something that runs as a user application? What besides the application itself needs access to these directories? What if any security concerns do you have for the application (either to protect it from other processes running on the system or to confine/restrict it)? > And why, for that matter, does running sealert give me the full path to > the executable, like openjdk... but *not* the full path to the file it's > trying to operate on, and I'm left going "ok, where was the file it > deleted? (we're running in permissive mode - overwhelmingly, developers > and subject matter experts no less than nothing about selinux). Kernel limitation; we don't have that information readily available (e.g. no vfsmount and/or dentry at that layer) or safely generatable (e.g. calling d_path at certain points can trigger a deadlock) at the point where the permission check occurs. It can be captured and reported however by turning on system call auditing and pathname collection in the following manner. This audit functionality is disabled by default due to its performance overhead. 1) Enable system call auditing and pathname reporting. Edit /etc/audit/rules.d/audit.rules (or /etc/audit/audit.rules if running a version that predates the introduction of /etc/audit/rules.d), and comment out the last line: #-a task,never Then add a watch or filter to turn on pathname collection: echo "-w /etc/shadow -p w" > /etc/audit/rules.d/shadow.rules The particular watch or filter is unimportant; it is the presence of any such watch/filter that turns on audit pathname collection. Just don't pick one that will trigger too often or you'll generate lots of irrelevant audit messages. Then you can run: service auditd reload And it should regenerate /etc/audit/audit.rules and reload that. 2) Re-run your application that was triggering the errors. Then run "ausearch -m avc -i -ts recent" (or similar) to view the audit records. You should then get a series of records, including a type=PROCTITLE (if supported by your kernel), type=PATH, type=CWD, type=SYSCALL, and type=AVC for each permission denial. These are generated at different points in the processing. All records with the same timestamp/serial number were generated during the same system call. (alternatively sealert might collect these up for you and present them more nicely; I don't know as I don't use it myself) 3) Restore your audit configuration to its original state if you want to avoid the performance overhead. rm /etc/audit/rules.d/shadow.rules Uncomment the last line of /etc/audit/rules.d/audit.rules. service auditd reload _______________________________________________ selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
