Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
+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 wrote: > > Ok, and what's about other VM arguments, not included to > IgniteSystemProperties? > > пт, 2 июл. 2021 г. в 09:27, Zhenya Stanilovsky : > >> >> -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).
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
An extra argument for IgniteSystemProperty sounds reasonable. -Val On Thu, Jul 1, 2021 at 10:04 AM Ivan Daschinsky 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 > > 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 : > > > > > > > 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 >
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
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 : > 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 > 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 : > > > > > 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 > > > > 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. > > > > > > > > > > > > > > > > > > с
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
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 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 > > 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 : > > > > > > > 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 pa
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
Why not mask the default known sensitive options using a blocklist? On Thu, 1 Jul 2021, 22:24 Shishkov Ilya, 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 > > 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 : > > > > > > > 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 > > > > > > > >: >
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
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 > 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 : > > > > > 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 > > > > 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 > >
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
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 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 : > > > 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 > > > 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 >: > > > > > > > > > > > > > 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
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
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 : > 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 > > 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 : > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
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 > 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 : > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
Hi, 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? чт, 1 июл. 2021 г. в 19:41, Ivan Daschinsky : > > Not all of them are OK to be printed out > Could you give an example please? As for me, all of them are pretty > harmless > > чт, 1 июл. 2021 г., 19:36 Valentin Kulichenko < > valentin.kuliche...@gmail.com > >: > > > 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 > > 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 : > > > > > > > > > > > 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/
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
> Not all of them are OK to be printed out Could you give an example please? As for me, all of them are pretty harmless чт, 1 июл. 2021 г., 19:36 Valentin Kulichenko : > 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 > 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 : > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
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 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 : > > > > > > > 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 >: > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > >
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
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 : > 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 Вячеслав Коптилин > > 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 : > > > > > 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 Вячеслав Коптилин >: > > > > > > > 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 : > > > > > > > > > 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 > > > > > > > > > > > > > > >
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
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 Вячеслав Коптилин 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 : > > > 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 Вячеслав Коптилин : > > > > > 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 : > > > > > > > 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 > > > > > > > > > >
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
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 : > 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 Вячеслав Коптилин : > > > 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 : > > > > > 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 > > > > > >
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
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 Вячеслав Коптилин : > 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 : > > > 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 > > >
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
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 : > 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 >
Re: Setting IGNITE_TO_STRING_INCLUDE_SENSITIVE=false prevents VM Arguments output
I suppose, that we should revert this particular line. I don't understand who ever considers vm options as sensitive info. ср, 30 июн. 2021 г., 22:52 Shishkov Ilya : > 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 >
