The vulnerability(CVE-2019-11244) is not completely eliminated

[RainbowMango]

What happened:
The PR(#77874) seems have fixed CVE-2019-11244.

But I doubt the correction didn't fix completely.

According to the description of CVE-2019-11244:

In Kubernetes v1.8.x-v1.14.x, schema info is cached by kubectl in the location specified by --cache-dir (defaulting to $HOME/.kube/http-cache), written with world-writeable permissions (rw-rw-rw-). If --cache-dir is specified and pointed at a different location accessible to other users/groups, the written files may be modified by other users/groups and disrupt the kubectl invocation.

The cache file created by kubectl should not be modified by other users/groups, or, to be more accurate, the file can only be modified by the user who runs the process.

But after the correction, the user in the same group still can write the cache file.
In the correction we have made the two changes:

• The path permission changed from 0755 to 0750. (I think it's ok. Allow user in the same group enter the path but can not modify the path, neither create nor delete a file in this path. Refuse all other users.)
• The cache file permission changed from 0755 to 0660. (This still allows the user in the same group modify the cache file.)

So, I think the file permission should be 0640. The user in the same group can only read the file.

What you expected to happen:
The cache file can only be modified by the user who runs the process, and the users in the same group can only have read permission.

How to reproduce it (as minimally and precisely as possible):

1. Create a path by root and set permission with 0755:
   # mkdir -m 0750 myPath0750

2. Create a file in it by root and set permission with 0660:
   # touch myPath0750/myFile0660
# chmod 0660 myPath0750/myFile0660

3. Create a new user in root group:
   # useradd -G root -d /home/horen -m horen
# passwd horen

4. Switch to new users and try to modify the file myPath0750/myFile0660.
   You will see the new user can modify the file.

Anything else we need to know?:
I don't know if there a scenario for users in the same group to modify the cache file. Please let me know if there is.

Environment:

• Kubernetes version (use kubectl version): N/A
• Cloud provider or hardware configuration: N/A
• OS (e.g: cat /etc/os-release): CentOS 7.0
• Kernel (e.g. uname -a):
• Install tools:
• Network plugin and version (if this is a network-related bug):
• Others:

[RainbowMango]

cc @liggitt

[RainbowMango]

/assign

[RainbowMango]

/sig api-machinery
/area security

[liggitt]

In some cases, it is expected that new files will be group-writeable.

Using os.Create() (or detecting default permissions at cache instantiation time) would honor the user's umask setting.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[RainbowMango]

/remove-lifecycle stale

[jiggyjigsj]

@RainbowMango This is still any active flag for us and was wondering if this is going to be looked any anytime soon? We have been flaged since Oct of 2019.

[RainbowMango]

@jiggyjigsj I remember @liggitt file a PR(#80813) for this but don't know why it stopped.

[jiggyjigsj]

@liggitt Is this something you got around to rebasing the pr or opened a new PR?