Security issue: jujud is not owned by a user on the system
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Fix Released
|
High
|
Unassigned |
Bug Description
While doing a security scan of a vm deployed by Juju the scan flags any file not owned by a valid user on the system. Only one file came back in violation of this security policy.
$ ls -al /var/lib/
-rwxr-xr-x 1 112 116 122694392 Jan 6 16:24 /var/lib/
jujud is the only file that I see in this directory not owned by a user on this system.
Can we fix this so the jujud is owned by a user on this system?
The security tool that found this problem is OpenSCAP and here is the description of the problem:
If any files are not owned by a user, then the cause of their lack of ownership should be investigated. Following this, the files should be deleted or assigned to an appropriate user.
Rationale:
Unowned files do not directly imply a security problem, but they are generally a sign that something is amiss. They may be caused by an intruder, by incorrect software installation or draft software removal, or by failure to remove all files belonging to a deleted account. The files should be repaired so they will not cause problems when accounts are created in the future, and the cause should be discovered and addressed.
Changed in juju: | |
status: | Incomplete → Triaged |
importance: | Undecided → High |
That seems very surprising. Usually the juju tools are installed either via
cloud-init or some other mechanism. Do you have any idea how this file
would have been created without being one of the users.
Is this an LXD container? Is it possible we created the file outside of the
container to seed it, and then launch the container?
John
=:->
On Mon, Jan 23, 2017 at 4:26 AM, Matt Bruzek <email address hidden>
wrote:
> Public bug reported: juju/tools/ 2.1-beta4- xenial- amd64/jujud juju/tools/ 2.1-beta4- /bugs.launchpad .net/bugs/ 1658549 /bugs.launchpad .net/juju- core/+bug/ 1658549/ +subscriptions
>
> While doing a security scan of a vm deployed by Juju the scan flags any
> file not owned by a valid user on the system. Only one file came back in
> violation of this security policy.
>
> $ ls -al /var/lib/
> -rwxr-xr-x 1 112 116 122694392 Jan 6 16:24 /var/lib/
> xenial-amd64/jujud
>
> jujud is the only file that I see in this directory not owned by a user
> on this system.
>
> Can we fix this so the jujud is owned by a user on this system?
>
> The security tool that found this problem is OpenSCAP and here is the
> description of the problem:
>
> If any files are not owned by a user, then the cause of their lack of
> ownership should be investigated. Following this, the files should be
> deleted or assigned to an appropriate user.
>
> Rationale:
>
> Unowned files do not directly imply a security problem, but they are
> generally a sign that something is amiss. They may be caused by an
> intruder, by incorrect software installation or draft software removal,
> or by failure to remove all files belonging to a deleted account. The
> files should be repaired so they will not cause problems when accounts
> are created in the future, and the cause should be discovered and
> addressed.
>
> ** Affects: juju-core
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to juju-
> core.
> https:/
>
> Title:
> Security issue: jujud is not owned by a user on the system
>
> To manage notifications about this bug go to:
> https:/
>