jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clinton H Goudie-Nice (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-2981) Access control logging
Date Tue, 21 Jul 2015 23:51:05 GMT

    [ 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 commented on OAK-2981:
--------------------------------------------

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.

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

> 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 [aklimets@adobe.com] 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)

Mime
View raw message