Why not mask the default known sensitive options using a blocklist? On Thu, 1 Jul 2021, 22:24 Shishkov Ilya, <shishkovi...@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.kuliche...@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 <ivanda...@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 <a...@apache.org>: > > > > > > > What if we allowed a blocklist of parameters that are never printed? > > > > > > > > On Thu, 1 Jul 2021, 22:06 Valentin Kulichenko, < > > > > valentin.kuliche...@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 < > ivanda...@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.kuliche...@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.kopti...@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 < > > ivanda...@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.kopti...@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 < > > > > > shishkovi...@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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
