Security issue: jujud is not owned by a user on the system

Bug #1658549 reported by Matt Bruzek
6
This bug affects 1 person
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/juju/tools/2.1-beta4-xenial-amd64/jujud
-rwxr-xr-x 1 112 116 122694392 Jan 6 16:24 /var/lib/juju/tools/2.1-beta4-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.

Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 1658549] [NEW] Security issue: jujud is not owned by a user on the system

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:
>
> 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/juju/tools/2.1-beta4-xenial-amd64/jujud
> -rwxr-xr-x 1 112 116 122694392 Jan 6 16:24 /var/lib/juju/tools/2.1-beta4-
> 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://bugs.launchpad.net/bugs/1658549
>
> Title:
> Security issue: jujud is not owned by a user on the system
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju-core/+bug/1658549/+subscriptions
>

Revision history for this message
Anastasia (anastasia-macmood) wrote :

We track Juju 2.x issues in "juju" project. Re-targeting :)

no longer affects: juju-core
Changed in juju:
status: New → Incomplete
Revision history for this message
Matt Bruzek (mbruzek) wrote :

Hi John,

This was the xenial ubuntu charm deployed on AWS so it was a VM not LXD. I pinged people in #juju on IRC and they suspected that the archive (tar.gz) that delivers the Juju binaries to the VM preserved the ownership when uncompressed. I suggest there must be a chown command run on the files after compression on this system. I tried looking into the Juju code but got pulled in another direction before completing my investigation.

Changed in juju:
status: Incomplete → Triaged
importance: Undecided → High
Revision history for this message
Heather Lanigan (hmlanigan) wrote :

At some point this has fixed:

$ ls -la /var/lib/juju/tools/3.0-beta1.1-ubuntu-amd64/jujud
-rwxr-xr-x 1 ubuntu ubuntu 147664896 Jan 4 22:21 /var/lib/juju/tools/3.0-beta1.1-ubuntu-amd64/jujud

Changed in juju:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.