Whitelisting whole dependency for script-security

[Oliver Gondža]

My plugin[1] is bringing a dependency to Jenkins to be used from groovy
scripts by admins. I am wondering how to whitelist all ats API (except
for "entry points" for which I will provide delegates in plugin to
perform permission checks). I would like to avoid polluting the
dependency with `@Whitelisted` annotations as well as keeping giant
whitelist file up-to-date with the dependency.

Before I get clever trying to implement my own `Whitelist`, I am
wondering if something like that was implemented before or whether some
guidelines exist.

[1] https://wiki.jenkins.io/display/JENKINS/Dumpling+Plugin

Thanks
--
oliver

[Jesse Glick]

On Mon, Oct 16, 2017 at 10:30 AM, Oliver Gondža <ogo...@gmail.com> wrote:
> I would like to avoid polluting the dependency with
> `@Whitelisted` annotations

If you are going to personally promise that a method you write is safe
for any script to call, you had better write that down in sources and
think about your decision in each case. Trying to add everything in a
code base to a whitelist by default is a very bad idea.

[Oliver Gondža]

I see your point, though from a library design standpoint I see no
reason to introduce dependencies on its _clients_. Whitelisting Jenkins
singatures is just a single aspect of a single client application -
consider there would be several clients like that each imposing similar
demands...

--
oliver

[Jesse Glick]

On Mon, Oct 16, 2017 at 1:20 PM, Oliver Gondža <ogo...@gmail.com> wrote:
> from a library design standpoint I see no reason to
> introduce dependencies on its _clients_.

You are talking about a plugin bundling some theoretically independent
library, so not able to use `@Whitelisted`? You could define your own
annotation for methods intended to be called in the public API, or if
you are really really sure you know what you are doing and have a very
simple mechanical rule for classifying such methods, then you can have
a programmatic whitelist; the only example I can think of:

https://github.com/jenkinsci/job-dsl-plugin/blob/b2c93e10e6bb0fb63362c0e041b1b2f2b4c8124c/job-dsl-plugin/src/main/groovy/javaposse/jobdsl/plugin/JobDslWhitelist.groovy#L14

[Oliver Gondža]

On 2017-10-17 00:06, Jesse Glick wrote:
> On Mon, Oct 16, 2017 at 1:20 PM, Oliver Gondža <ogo...@gmail.com> wrote:
>> from a library design standpoint I see no reason to
>> introduce dependencies on its _clients_.
>
> You are talking about a plugin bundling some theoretically independent
> library, so not able to use `@Whitelisted`?

Yes.

> You could define your own
> annotation for methods intended to be called in the public API, or if
> you are really really sure you know what you are doing and have a very
> simple mechanical rule for classifying such methods, then you can have
> a programmatic whitelist

Yes, I guess I will have to - whitelisting whole classes / packages
while making sure they are coming from plugin jar. Thanks!
--
oliver

[Oliver Gondža]

Hmm, I have a followup up question.

I managed to whitelist safe calls and blacklist the dangerous ones to
steer users towards plugin API where I need to perform permission check
to make sure the powerful stuff is used by authorized users only.
However, I seems to misunderstand the concept of "signatures approved
presuming permission check" which I presume is here to do just that.

What `AclAwareWhitelist`/`@Whitelisted(restricted=true)` seems to be
doing is rejecting the signature when executed as SYSTEM - which is
always the case when run during build.

Is there a way to permit the signature and have it actually checked for
permission for the user that _introduced_ the script to Jenkins at
runtime? Implementation wise there is probably no other way than capture
the identify of the user and try to impersonate it while executing given
signature - which sounds fragile.

How do I use that for scripts executed during builds?

--
oliver

[Daniel Beck]

> On 19. Oct 2017, at 12:25, Oliver Gondža <ogo...@gmail.com> wrote:
>
> which is always the case when run during build.

https://plugins.jenkins.io/authorize-project ?