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:00:43 GMT
Ilya,

I don't think this is the best approach because there are so many
properties that contain so many different types of information. "All or
nothing" doesn't really fit here. We want to have the ability to exclude
sensitive information, but still print out internal settings that are
useful for debugging, etc.

-Val

On Thu, Jul 1, 2021 at 9:54 AM Shishkov Ilya <shishkovilja@gmail.com> wrote:

> Folks,
>
> > Maybe we should add an extra JVM option (e.g.
> IGNITE_FORCE_PRINT_VM_ARGUMENTS) which is 'false' by default,
> > but if set to 'true' then #ackVmOptions will print VM arguments even if
> sensitive data is restricted?
>
> What do you think about an extra JVM option?
>
> чт, 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