Stephen Smalley wrote:
> 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?
That's usually what I said means. And I'm the sysadmin - there's multiple
teams developing and enhancing a good number of systems, from websites to
computation.
> And if so, do you mean something that runs as a service/daemon or
> something that runs as a user application?
Webiste application, tomcat application, and user applications.
> What besides the application itself needs access to these directories?
I'm not involved, so I don't know, but I would think that application is
what needs to access it, and they may create directories and
subdirectories on the fly, and possibly delete them.
> 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)?
We're not that worried about other processes. Our security is being
scanned, as it is, by the IRT and pen testers. Me... I just want to shut
up selinux so it stops flooding our logs, and, when in production, in the
event that some day we're required to make selinux enforcing, I REALLY
don't want that to break anything.
>
>> 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.
>
Given that some jobs can run hours or days, I'm not going there.
<snip>
> 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.
That's what I'll probably try.
Thanks a lot, more things added to my to-do list. <g>
mark
_______________________________________________
selinux mailing list -- selinux@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to selinux-leave@xxxxxxxxxxxxxxxxxxxxxxx
