[
https://issues.apache.org/jira/browse/OAK-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14636029#comment-14636029
]
Clinton H Goudie-Nice edited comment on OAK-2981 at 7/22/15 3:21 PM:
---------------------------------------------------------------------
I have been thinking about this topic over the last couple of weeks.
I find ACL allow/deny audit logging is a fairly well established pattern in our
industry:
* Windows has permission allow/deny logging in the system event viewer. [1]
* Linux has detailed audit logging for file access. [2]
* When Linux added SELinux, it also added this type of allow/deny audit logging
for development and production purposes. [3]
*My thoughts for development:*
If my viewpoint is to improve upon the current security model, not maintain the
status quo, then I agree with [~anchela], this tooling would not improve the
security. It would only allow me to replicate what a service is already doing,
and probably not completely. I am limiting conceptual privilege escalation at
the risk of introducing bugs. Worse, I'm probably obfuscating an area that must
be reviewed by someone with more domain knowledge.
If I am developing something new, but using something existing that is
expecting an admin session. I'd like to follow a boy-scout motto, and "leave it
cleaner than I found it." If I don't have the resources to completely redesign
something existing, should I run the tool and try to help?
If I know mostly what this existing service does, this tooling would be
valuable to inform my development and prevent me from introducing bugs. It's
probably a good idea as an iterative step.
If I am not informed enough, running the tool and blindly whitelisting will
likely lead to bugs. It's probably better to leave things as is.
If I'm writing a new service from the ground up, I should already know the
permissions needed; I shouldn't need this logging.
*My thoughts for production environments:*
I would _expect_ this capability of a production system. DISA (US DoD) requires
vendors of systems with access control provide this capability. Many
organizations also require the capability to enable detailed audit logging.
If you are trying to isolate something rogue happening on your system, this
type of logging is irreplaceable. Without it you are forced to take guesses
where the intrusion is happening.
[1] https://technet.microsoft.com/en-us/library/Dn319056.aspx
[2]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html
[3]
https://wiki.gentoo.org/wiki/SELinux/Tutorials/Where_to_find_SELinux_permission_denial_details
I think this would be a useful tool, and with any tool, you must use it in the
right way. I would like to see it's inclusion with documentation around proper
use and best practices.
was (Author: cgoudie):
I have been thinking about this topic quite a bit over the last couple of weeks.
I find ACL allow/deny audit logging is a fairly well established pattern in our
industry:
* Windows has permission allow/deny logging in the system event viewer. [1]
* Linux has detailed audit logging for file access. [2]
* When Linux added SELinux, it also added this type of allow/deny audit logging
for development and production purposes. [3]
My thoughts for development:
If my viewpoint is to improve upon the current security model, not maintain the
status quo, then I agree with [~anchela], this tooling would not improve the
security. It would only allow me to replicate what a service is already doing,
and probably not completely. I am limiting conceptual privilege escalation at
the risk of introducing bugs. Worse, I'm probably obfuscating an area that must
be reviewed by someone with more domain knowledge.
If I am developing something new, but using something existing that is
expecting an admin session. I'd like to follow a boy-scout motto, and "leave it
cleaner than I found it." If I don't have the resources to completely redesign
something existing, should I run the tool and try to help?
If I know mostly what this existing service does, this tooling would be
valuable to inform my development and prevent me from introducing bugs. It's
probably a good idea as an iterative step.
If I am not informed enough, running the tool and blindly whitelisting will
likely lead to bugs. It's probably better to leave things as is.
If I'm writing a new service from the ground up, I should already know the
permissions needed; I shouldn't need this logging.
My thoughts for production environments:
I would expect this capability of a production system. DISA (US DoD) requires
vendors of systems with access control provide this capability. Many
organizations also require the capability to enable detailed audit logging.
If you are trying to isolate something rogue happening on your system, this
type of logging is irreplaceable. Without it you are forced to take guesses
where the intrusion is happening.
[1] https://technet.microsoft.com/en-us/library/Dn319056.aspx
[2]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/chap-system_auditing.html
[3]
https://wiki.gentoo.org/wiki/SELinux/Tutorials/Where_to_find_SELinux_permission_denial_details
I think this would be a useful tool, and with any tool, you must use it in the
right way. I would like to see it's inclusion with documentation around proper
use and best practices.
> Access control logging
> ----------------------
>
> Key: OAK-2981
> URL: https://issues.apache.org/jira/browse/OAK-2981
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: core
> Reporter: Alexander Klimetschek
> Assignee: angela
> Priority: Minor
>
> For debugging application behavior and designing ACLs it is useful to have a
> logging of JCR operations and also see if access was granted or not.
> I hacked a quick solution that gives this result:
> {noformat}
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /jcr:system/rep:namespaces/rep:nsdata/http%3A%2F%2Fsling.apache.org%2Fjcr%2Fevent%2F1.0
> [read property]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254 [read]
> 10.06.2015 15:29:43.658 [admin] ALLOWED
> /var/eventing/jobs/assigned/862f413b-6f03-40a1-aa10-550af9970254/jcr:primaryType
> [read property]
> 10.06.2015 15:30:10.484 [[email protected]] DENIED
> /libs/wcm/core/content/contentfinder [read]
> 10.06.2015 15:25:12.421 [admin] ALLOWED
> /var/classes/862f413b-6f03-40a1-aa10-550af9970254/sightly/1.0.2/apps/ccebasic/ui/commons/breadcrumbs/SightlyJava_breadcrumbs.java/jcr:content/jcr:content
> [REMOVE_NODE,ADD_NODE]
> {noformat}
> See on my github fork:
> https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2
> Change against the 1.2 branch. [As patch
> file|https://github.com/alexkli/jackrabbit-oak/commit/f4ecf7ca6b7d8c7e1d6967d409be4045a634efe2.patch].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
