ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
Date Thu, 01 Jul 2021 17:07:08 GMT
An extra argument for IgniteSystemProperty sounds reasonable.

-Val

On Thu, Jul 1, 2021 at 10:04 AM Ivan Daschinsky <ivandasch@gmail.com> wrote:

> Ok, this can be excluded using blocklist-jvm-params.properties or just by
> providing and extra arg to annotation, as I have just suggested
>
> чт, 1 июл. 2021 г., 19:51 Valentin Kulichenko <
> valentin.kulichenko@gmail.com
> >:
>
> > Ivan,
> >
> > IP addresses (e.g. IGNITE_TCP_DISCOVERY_ADDRESSES) and file paths
> > (e.g. IGNITE_CONFIG_URL) are often considered sensitive information. Data
> > related to authentication (e.g. IGNITE_SSH_USER_NAME) is very likely to
> be
> > sensitive.
> >
> > Once again - I would exclude any property that can contain user-specific
> > information. Only our internal settings (stuff
> > like IGNITE_SQL_MERGE_TABLE_MAX_SIZE) are OK to appear in the logs.
> >
> > -Val
> >
> > On Thu, Jul 1, 2021 at 9:47 AM Ivan Daschinsky <ivandasch@gmail.com>
> > wrote:
> >
> > > We can add add an extra param in annotation, that blocks param to be
> > > printed, just set it to false by default and block it wheb set to true
> > >
> > > чт, 1 июл. 2021 г., 19:45 Atri Sharma <atri@apache.org>:
> > >
> > > > What if we allowed a blocklist of parameters that are never printed?
> > > >
> > > > On Thu, 1 Jul 2021, 22:06 Valentin Kulichenko, <
> > > > valentin.kulichenko@gmail.com> wrote:
> > > >
> > > > > Not all of them are OK to be printed out. At the very least, we
> > should
> > > > have
> > > > > a mechanism to exclude some of them. I would still go with opt-in
> > > rather
> > > > > than opt-out though, but I guess that is up to a discussion.
> > > > >
> > > > > -Val
> > > > >
> > > > > On Thu, Jul 1, 2021 at 9:29 AM Ivan Daschinsky <
> ivandasch@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > This is security through obscurity, an obvious and a well-known
> > anti
> > > > > > pattern. I suppose that printing jvm options, that is registered
> by
> > > > > > @IgniteSystemProperty annotation is an ideal variant
> > > > > >
> > > > > > чт, 1 июл. 2021 г., 19:25 Valentin Kulichenko <
> > > > > > valentin.kulichenko@gmail.com
> > > > > > >:
> > > > > >
> > > > > > > Folks,
> > > > > > >
> > > > > > > *Anything* that a user provides to the system can potentially
> be
> > > > > > considered
> > > > > > > sensitive information. This includes the VM arguments.
We can't
> > > > predict
> > > > > > > what exactly one can put there, so let's not make assumptions.
> > > > > > >
> > > > > > > When dealing with security, we should be as conservative
as
> > > possible.
> > > > > > That
> > > > > > > said, I do not even agree with the pattern approach - there
> might
> > > be
> > > > a
> > > > > > > user's system property named IGNITE_xxx. It is also possible
> for
> > > our
> > > > > > > internal properties to contain sensitive information (not
all
> of
> > > them
> > > > > are
> > > > > > > boolean flags).
> > > > > > >
> > > > > > > The only option I see is to print out specific properties
for
> > which
> > > > we
> > > > > > > agree that they are safe. For example, we can introduce
an
> > > annotation
> > > > > > that
> > > > > > > would mark "safe" properties in IgniteSystemProperties;
we will
> > > then
> > > > > > print
> > > > > > > out only those that are marked with the annotation.
> > > > > > >
> > > > > > > -Val
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jul 1, 2021 at 7:07 AM Вячеслав Коптилин
<
> > > > > > slava.koptilin@gmail.com
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hello Ivan,
> > > > > > > >
> > > > > > > > > At least, we could just hide params that match
a specific
> > > pattern
> > > > > > > > Yes, we can filter out all vm options that do not
relate to
> > > Ignite,
> > > > > for
> > > > > > > > instance.
> > > > > > > >
> > > > > > > > > Ilya, go ahead, file ticket and prepare a PR.
> > > > > > > > Please do not rush. Let's listen to other community
members.
> > This
> > > > > > > question
> > > > > > > > is about security and it should not be discussed in
a hurry
> > (even
> > > > > > though
> > > > > > > it
> > > > > > > > looks like an obvious thing).
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > S.
> > > > > > > >
> > > > > > > > чт, 1 июл. 2021 г. в 16:55, Ivan Daschinsky
<
> > ivandasch@gmail.com
> > > >:
> > > > > > > >
> > > > > > > > > I suppose, that all normal users should not suffer
from
> this
> > > > > > > > restrictions.
> > > > > > > > > Nobody will pass password using jvm options.
It is
> absolutely
> > > > > insane,
> > > > > > > > > normal users pass passwords using environment
variables.
> > > > > > > > >
> > > > > > > > > At least, we could just hide params that match
specific
> > pattern
> > > > > > > > >
> > > > > > > > > Ilya, go ahead, file ticket and prepare a PR.
> > > > > > > > >
> > > > > > > > > чт, 1 июл. 2021 г., 16:45 Вячеслав
Коптилин <
> > > > > > slava.koptilin@gmail.com
> > > > > > > >:
> > > > > > > > >
> > > > > > > > > > Hello,
> > > > > > > > > >
> > > > > > > > > > Unfortunately, the user can pass its own
system
> properties
> > > via
> > > > > JVM
> > > > > > > > > options
> > > > > > > > > > as follows: -DMY_SECRET_PASSWORD=123
> > > > > > > > > > It does not seem, this approach is the best
one. However,
> > the
> > > > > user
> > > > > > > > should
> > > > > > > > > > have a "kostyl" in order to hide these properties
and
> > values
> > > in
> > > > > the
> > > > > > > log
> > > > > > > > > > file, IMHO.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > S.
> > > > > > > > > >
> > > > > > > > > > ср, 30 июн. 2021 г. в 22:52, Shishkov
Ilya <
> > > > > shishkovilja@gmail.com
> > > > > > >:
> > > > > > > > > >
> > > > > > > > > > > Hi Igniters,
> > > > > > > > > > >
> > > > > > > > > > > This feature [1, 2] prevents logging
of the VM
> arguments
> > > when
> > > > > > > > > > > IGNITE_TO_STRING_INCLUDE_SENSITIVE
option is set to
> > false.
> > > > Till
> > > > > > > now,
> > > > > > > > > > method
> > > > > > > > > > > IgniteKernal#ackVmArguments remains
mostly the same
> [3].
> > > > > > > > > > >
> > > > > > > > > > > Is this behaviour actual now? Often,
we should be able
> to
> > > get
> > > > > > from
> > > > > > > > logs
> > > > > > > > > > the
> > > > > > > > > > > actual VM options used at startup even
if output of
> > > sensitive
> > > > > > data
> > > > > > > is
> > > > > > > > > > > restricted.
> > > > > > > > > > >
> > > > > > > > > > > 1. https://issues.apache.org/jira/browse/IGNITE-4991
> > > > > > > > > > > 2.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/ignite/pull/2428/commits/4f90b6fd77bd23fa818620f0757b792ba388ef93
> > > > > > > > > > > 3.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L3002
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message