Bug 987595 - Better support for SELinux contexts when debugging daemons
Better support for SELinux contexts when debugging daemons
Status: NEW
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Sergio Durigan Junior
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-23 14:25 EDT by Dave Malcolm
Modified: 2018-05-14 05:06 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dave Malcolm 2013-07-23 14:25:41 EDT
Description of problem:
I'm filing this to capture a discussion on RH's memo-list about SELinux and gdb:

>>>> If you have to start a daemon under gdb, you may get denials because
>>>> you don't start it in the right context.  Or you may get denials later
>>>> because you started it in the wrong context, and it created files in
>>>> the wrong context that cause denials when start it in the right
>>>> context.

[snip discussion of attaching to inferior rather than launching, so as to get it in the correct SELinux context]

>> This sounds like it should be filed as an RFE against gdb in bugzilla: have
>> gdb be able to start a debugged process in the correct context.
>> 
>Easier said then done. Are you asking that the gdm would have runcon built
>in, so you could say something like
>
>gdb> set context="system_u:system_r:foobar_t:s0"
>gdb> r CMDARGS
>
>Or are you hoping gdb figures out what the right context would be,  A much
>harder problem in that executing foobar_exec_t from unconfined_t would get one
>label while executing foobar_exec_t from init_t would get a different label.

I'm not sure what the correct behavior should be, but it seemed best to file it here so we can have the discussion here.

Perhaps gdb could somehow notice that transition rules exist for an executable, and somehow offer to switch when launching the inferior?
Comment 1 Jan Kratochvil 2013-07-23 14:39:20 EDT
So far giving NEEDINFO to it:
I agree that the context should be set automatically (is it possible?).
If it cannot work as with "init" parent will it help at all?
Otherwise could we get some sample set of SELinux API calls to implement it?
Comment 2 Daniel Walsh 2013-07-23 15:18:55 EDT
Well SELinux labeling is based on the label of the calling process and the label of the executable.

This is called process transitions.

There is SELinux api to ask, if process labeled A executed executable labeled B what label would the kernel launch be with?
Comment 3 Daniel Walsh 2013-07-23 15:20:31 EDT
But we would still have the problem that gdb could only get the label of the process it is running as, most likely unconfined_t.

One other problem which we would need to fix with policy would be to allow unconfined_t to transition to all domains that init_t can transition to.
Comment 4 Eric Paris 2013-07-23 16:23:12 EDT
So the real problem here has little to do with gdb.  Is has to do with the difference between launching daemons from systemd and from the command line.  gdb just is a big reason you might want to launch a reason as an admin rather than from init.

It should be possible for gdb (or libselinux maybe) to determine what the context would be if it was launched by init.  It would need to figure out the context of init (it should be in /sys/fs/selinux/initial_contexts/init (although it doesn't seem correct)    gdb should then be able to query on the transition from the init context.  Then just use setexeccon() on that label before calling exec.

That does leave the policy issue, of unconfined not being able to use setexeccon, but I always thought that should be fixed in policy anyway...
Comment 5 Daniel Walsh 2013-07-24 18:33:40 EDT
How about 

getpidcon(1, &scon)

Or

cat /proc/1/attr/current 
system_u:system_r:init_t:s0


db68fe003355748bc7ebeb7895a755d48633b5d4 allows unconfined_t to transition to any domain.  There is still a problem of entrypoints
Comment 6 Daniel Walsh 2013-07-24 18:39:41 EDT
Something like the following, if you were sure it was an init daemon

security_context_t initcon;
security_context_t fcon;
security_contex_t  newcon;

getpidcon(1,&initcon);
getfilecon(EXECUTABLE_PATH, &fcon);

security_compute_create(initcon, fcon, SECCLASS_PROCESS, &newcon);
setexeccon(newcon);
freecon(initcon)
freecon(fcon)
freecon(newcon)

I still think we should allow user to specify the context also to handle cases where it is not an init daemon.

set context = "system_u:system_r:svirt_t:s0:c1,c2"

setexecon()
Comment 7 Daniel Walsh 2013-07-25 17:17:00 EDT
After talking to Dave Malcolm, we came to the conclusion that what we really need is a way for gdb to work with systemd to launch the debugged application within the unit file and have it break at main.

systemctl gdb httpd.service

or something like this.

Since services are running in a totally different environment then when run directly.

systemd is cleaning up the Environment, transitioning to the proper SELinux context, potentially setting up namespaces, mounting file systems, potentially changing the UID, having loginuid and session id of the processes cleared.

This is really more then just an SELinux issue.
Comment 8 Jan Kratochvil 2013-07-25 17:24:26 EDT
(In reply to Daniel Walsh from comment #7)
> and have it break at main.

"main" is too late, it should break at _start (entry point), people for example debug static C++ constructors.

For example after PTRACE_O_TRACEEXEC stopped the process, PTRACE_DETACH it with data==SIGSTOP and then GDB can attach to such stopped (Status 'T') process.
Comment 9 Tom Tromey 2013-07-26 13:30:50 EDT
Perhaps we should investigate the generic "global breakpoints"
approach instead.  The plus side of this is that it isn't specific
to things started via systemd, and so it addresses a common user
question ("how do I debug my program which is super complicated to
start up?").  Ref: http://sourceware.org/ml/gdb-patches/2011-06/msg00163.html
Comment 10 Fedora End Of Life 2013-09-16 10:43:40 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Comment 11 Fedora End Of Life 2015-05-29 05:12:58 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 12 Jan Kurik 2015-07-15 10:46:49 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
Comment 13 Fedora End Of Life 2016-11-24 06:00:21 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Note You need to log in before you can comment on or make changes to this bug.