+1 to Ivan’s idea about adding extra param to IgniteSystemProperties.
> Ok, and what's about other VM arguments, not included to > IgniteSystemProperties? IMO all VM arguments should be considered sensitive except those annotated with @IgniteSystemProperties(sensitive=false). -- Regards, Konstantin Orlov > On 2 Jul 2021, at 20:52, Shishkov Ilya <shishkovi...@gmail.com> wrote: > > Ok, and what's about other VM arguments, not included to > IgniteSystemProperties? > > пт, 2 июл. 2021 г. в 09:27, Zhenya Stanilovsky <arzamas...@mail.ru.invalid>: > >> >> -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 < ivanda...@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.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 >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >> >> >>
