Get error ASLR disable failed: EPERM: Operation not permitted when executing cargo tarpaulin -v

[new-commer]

I use root user , and get the error ASLR disable failed: EPERM: Operation not permitted when executing cargo tarpaulin -v. And i tried sudo cargo tarpaulin -v , it prompt cargo command not found
So i tried sudo -s cargo tarpaulin -v , it also prompt ASLR disable failed: EPERM: Operation not permitted .How can i resolve it ?

[xd009642]

So what environment are you running in? A CI server (if so which one) or your personal machine? This issue is a duplicate of #77 so you may find help there. ASLR is a security measure to stop malicious processes inspecting the memory or altering the execution of a process (including arbitrary code execution). So you may need to change a security rule via seccomp to allow tarpaulin to disable ASLR.

As for how to do that I'm not sure but maybe running tarpaulin with setarch -R will work

[new-commer]

Yeah it run in docker started by gitlab-ci runner . And i have seen issue #77 .
My CI server is not travis-ci , and the workaround for #77 do not fit gitlab-ci
Is there any workaround (such as modify .gitlab-ci.yml) ?

[new-commer]

BTW , why Tarpaulin can run in personal machine(centos system ) , just use normal user ( the user have no authority to disable ALSR). And it can not work in docker , even though use root user ?

[xd009642]

Because the user does have authority to disable ALSR by default, it's just things like docker or CI servers add some extra security restrictions to keep the systems and other users safe. If you're running docker the docker section of the readme might be helpful https://github.com/xd009642/tarpaulin#docker

[xd009642]

@new-commer Have you tried the method in the docker section of the readme? And has it solved your issue?

[new-commer]

@xd009642 Thanks for your help . We have tried and it works . And we're trying to do that in gitlab-ci now . If no one is familiar with gitlab-ci here, I will investigate it myself. Now I will close this issue .

[gdesmott]

@new-commer : did you find any way to make this work with gitlab-ci? I'm hitting the same problem.

[xd009642]

You might be able to get it to work using the docker image in gitlab. Although I tried it myself on a test project last weekend and it worked fine (using tarpaulin version 0.9.1)

…

On Tue, Nov 5, 2019 at 10:47 AM Guillaume Desmottes < ***@***.***> wrote: @new-commer <https://github.com/new-commer> : did you find any way to make this work with gitlab-ci? I'm hitting the same problem. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#146?email_source=notifications&email_token=AA2PZBWRO5LISTWKDTI3D73QSFFLVA5CNFSM4FTQC4NKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDCNCNI#issuecomment-549769525>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2PZBT3AFE67UIKIZTGSTLQSFFLVANCNFSM4FTQC4NA> .

[ThibsG]

Hi, just to help if someone is experiencing same issue using a custom built image for the runner.

You can also add security_opt option to your runner configuration file /etc/gitlab-runner/config.toml:

[[runners]]
  [runners.docker]
    security_opt = ["seccomp:unconfined"]

Then restart gitlab-runner service in order to reload configuration.

Note that as said in other issues this option can also be used when running a container by hand:
$ docker run --rm -it --security-opt seccomp=unconfined ...

It could be interesting to add this to a Wiki/FAQ page.

[rye]

Just to provide more background for people in situations where seccomp=unconfined is too liberal, one can also use a modified seccomp profile. Per the Docker documentation on seccomp, a number of syscalls are restricted through the default seccomp policy, including the personality syscall which is how tarpaulin and other tools that require ASLR to be disabled can request so. (Edit: This is the reason why the default configuration doesn't allow tarpaulin to work.)

Docker's built-in default seccomp policy does allow the use of the personality syscall in certain cases, but only with the arguments 0x8, 0x2_0000, 0x2_0008, and 0xffff_ffff (GET_PERSONA), apparently.

The current method of disabling ASLR does not match one of the requested values, so is rejected by the kernel:

tarpaulin/src/process_handling/linux.rs

Lines 35 to 43 in c5e8e09

	fn disable_aslr() -> nix::Result<i32> {
	match personality(GET_PERSONA) {
	Ok(p) => match personality(i64::from(p) | ADDR_NO_RANDOMIZE) {
	ok @ Ok(_) => ok,
	err @ Err(..) => err,
	},
	err @ Err(..) => err,
	}
	}

All of this is to say that one could add the object

{
  "names": [
    "personality"
  ],
  "action": "SCMP_ACT_ALLOW",
  "args": [
    {
      "index": 0,
      "value": 262144,
      "valueTwo": 0,
      "op": "SCMP_CMP_EQ"
    }
  ],
  "comment": "Enable personality(ADDR_NO_RANDOMIZE) syscall",
  "includes": {},
  "excludes": {}
}

to the syscalls key in their seccomp JSON file to allow ASLR disables to succeed. (If the persona is somehow different than just 0, the "value" might need tuning.)