ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zhenya Stanilovsky <arzamas...@mail.ru.INVALID>
Subject Re[2]: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
Date Fri, 02 Jul 2021 06:27:06 GMT

-1 for extra arg, +1 for Ivan`s upper proposal : @IgniteSystemProperty annotation.
Look, someone will set some of IGNITE_* option and after possibly cluster problems will give
this logs into analysis and engineer can`t reproduce such a case, cause no param is applied.
 
>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