open_init_pty function?

open_init_pty function?

[eric gisse]

In tracking down some related issues, the subject of the helper
program /usr/sbin/open_init_pty came up.

This gets called by run_init as the final step for running a program
in the initrc context, like this:

if (execvp("/usr/sbin/open_init_pty", argv)) {
  perror("execvp");
  exit(-1);
}

The context for this problem is the discovery that open_init_pty
doesn't play well with others by refusing to pass along return codes.
Eg, run_init from stock will always return 0.

Debian fixes this problem by fixing open_init_pty to return status
codes, redhat bypasses it in favor of execvp(), and gentoo uses stock
and is evaluating its' options.

What I'm trying to figure out is, is the function of open_init_pty in
the general sense.

Init scripts don't generally get a pty, so I don't understand the
necessity and hope someone here can shed a little light on this.

Re: open_init_pty function?

[Christopher J. PeBenito]

On 12/15/2014 6:32 AM, eric gisse wrote:
> In tracking down some related issues, the subject of the helper
> program /usr/sbin/open_init_pty came up.
> 
> This gets called by run_init as the final step for running a program
> in the initrc context, like this:
> 
> if (execvp("/usr/sbin/open_init_pty", argv)) {
>   perror("execvp");
>   exit(-1);
> }
> 
> The context for this problem is the discovery that open_init_pty
> doesn't play well with others by refusing to pass along return codes.
> Eg, run_init from stock will always return 0.
> 
> Debian fixes this problem by fixing open_init_pty to return status
> codes, redhat bypasses it in favor of execvp(), and gentoo uses stock
> and is evaluating its' options.
> 
> What I'm trying to figure out is, is the function of open_init_pty in
> the general sense.
> 
> Init scripts don't generally get a pty, so I don't understand the
> necessity and hope someone here can shed a little light on this.

Most daemons will print early error messages before reopening their
stdin/out/err to /dev/null.  The purpose of open_init_pty is to provide
an isolated stdin/out/err for the init scripts and daemons.  Without it,
we'd have to allow all daemons to read/write sysadm/unconfined
terminals, which opens those highly-privileged users to attack.


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Re: open_init_pty function?

[eric gisse]

Thanks, that helps a lot. The consensus on what you said basically
boils down to "enforcing a new tty ensures that, among other things,
the executed process can't play games with the calling domain's file
descriptors".

I'm a bit fuzzy on how to exploit this and how big of a deal it could
be in practice because, in theory, selinux should keep a process I
spawn from tinkering with anything directly.

This does, by the way, answer the question of why the redhat patch
that disables this behavior was either never submitted or never
accepted upstream.

Though I wonder why redhat is OK with disabling this, given the ease
of implementing this additional security measure. I only got pulled
into this because the stock run_init does not properly pass status
codes.

I was thinking that entire code block could go away because the way
the utility was worded, was that it was providing a ptty for init
scripts because the init scripts *needed* the ptty rather than being
as some value of exec STDIO filtering / FD protection / whatever.

I was asking both gentoo and debian maintainers of this as well as
other random folks and nobody saw the value of this. I still have a
hard time wrapping my head around the problem this solves but the cost
of doing it this way is zero, as long as a tiny little bit of work
(that debian already did) to pass status codes is done.

Which is all I wanted in the first place.

run_init likes to clobber status codes, which breaks my puppet.


On Mon, Dec 15, 2014 at 7:55 AM, Christopher J. PeBenito
<cpebenito@tresys.com> wrote:
> On 12/15/2014 6:32 AM, eric gisse wrote:
>> In tracking down some related issues, the subject of the helper
>> program /usr/sbin/open_init_pty came up.
>>
>> This gets called by run_init as the final step for running a program
>> in the initrc context, like this:
>>
>> if (execvp("/usr/sbin/open_init_pty", argv)) {
>>   perror("execvp");
>>   exit(-1);
>> }
>>
>> The context for this problem is the discovery that open_init_pty
>> doesn't play well with others by refusing to pass along return codes.
>> Eg, run_init from stock will always return 0.
>>
>> Debian fixes this problem by fixing open_init_pty to return status
>> codes, redhat bypasses it in favor of execvp(), and gentoo uses stock
>> and is evaluating its' options.
>>
>> What I'm trying to figure out is, is the function of open_init_pty in
>> the general sense.
>>
>> Init scripts don't generally get a pty, so I don't understand the
>> necessity and hope someone here can shed a little light on this.
>
> Most daemons will print early error messages before reopening their
> stdin/out/err to /dev/null.  The purpose of open_init_pty is to provide
> an isolated stdin/out/err for the init scripts and daemons.  Without it,
> we'd have to allow all daemons to read/write sysadm/unconfined
> terminals, which opens those highly-privileged users to attack.
>
>
> --
> Chris PeBenito
> Tresys Technology, LLC
> www.tresys.com | oss.tresys.com

Re: open_init_pty function?

[Christopher J. PeBenito]

On 12/15/2014 11:33 AM, eric gisse wrote:
> Thanks, that helps a lot. The consensus on what you said basically
> boils down to "enforcing a new tty ensures that, among other things,
> the executed process can't play games with the calling domain's file
> descriptors".
> 
> I'm a bit fuzzy on how to exploit this and how big of a deal it could
> be in practice because, in theory, selinux should keep a process I
> spawn from tinkering with anything directly.

Consider the bash session the admin is running.  If the admin runs
su/sudo, the daemon can simply read the terminal to capture the admin's
password when they enter it.  Similarly, as the admin runs programs, the
daemon could write to the terminal to inject data into the admin
processes.  You could deny this terminal access to close this hole, but
the trade off is that you lose any early messages (error or otherwise)
the daemon sends when you run_init.



> This does, by the way, answer the question of why the redhat patch
> that disables this behavior was either never submitted or never
> accepted upstream.
> 
> Though I wonder why redhat is OK with disabling this, given the ease
> of implementing this additional security measure. I only got pulled
> into this because the stock run_init does not properly pass status
> codes.
> 
> I was thinking that entire code block could go away because the way
> the utility was worded, was that it was providing a ptty for init
> scripts because the init scripts *needed* the ptty rather than being
> as some value of exec STDIO filtering / FD protection / whatever.
> 
> I was asking both gentoo and debian maintainers of this as well as
> other random folks and nobody saw the value of this. I still have a
> hard time wrapping my head around the problem this solves but the cost
> of doing it this way is zero, as long as a tiny little bit of work
> (that debian already did) to pass status codes is done.
> 
> Which is all I wanted in the first place.
> 
> run_init likes to clobber status codes, which breaks my puppet.
> 
> 
> On Mon, Dec 15, 2014 at 7:55 AM, Christopher J. PeBenito
> <cpebenito@tresys.com> wrote:
>> On 12/15/2014 6:32 AM, eric gisse wrote:
>>> In tracking down some related issues, the subject of the helper
>>> program /usr/sbin/open_init_pty came up.
>>>
>>> This gets called by run_init as the final step for running a program
>>> in the initrc context, like this:
>>>
>>> if (execvp("/usr/sbin/open_init_pty", argv)) {
>>>   perror("execvp");
>>>   exit(-1);
>>> }
>>>
>>> The context for this problem is the discovery that open_init_pty
>>> doesn't play well with others by refusing to pass along return codes.
>>> Eg, run_init from stock will always return 0.
>>>
>>> Debian fixes this problem by fixing open_init_pty to return status
>>> codes, redhat bypasses it in favor of execvp(), and gentoo uses stock
>>> and is evaluating its' options.
>>>
>>> What I'm trying to figure out is, is the function of open_init_pty in
>>> the general sense.
>>>
>>> Init scripts don't generally get a pty, so I don't understand the
>>> necessity and hope someone here can shed a little light on this.
>>
>> Most daemons will print early error messages before reopening their
>> stdin/out/err to /dev/null.  The purpose of open_init_pty is to provide
>> an isolated stdin/out/err for the init scripts and daemons.  Without it,
>> we'd have to allow all daemons to read/write sysadm/unconfined
>> terminals, which opens those highly-privileged users to attack.


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Re: open_init_pty function?

[Daniel J Walsh]

On 12/15/2014 01:26 PM, Christopher J. PeBenito wrote:
> On 12/15/2014 11:33 AM, eric gisse wrote:
>> Thanks, that helps a lot. The consensus on what you said basically
>> boils down to "enforcing a new tty ensures that, among other things,
>> the executed process can't play games with the calling domain's file
>> descriptors".
>>
>> I'm a bit fuzzy on how to exploit this and how big of a deal it could
>> be in practice because, in theory, selinux should keep a process I
>> spawn from tinkering with anything directly.
> Consider the bash session the admin is running.  If the admin runs
> su/sudo, the daemon can simply read the terminal to capture the admin's
> password when they enter it.  Similarly, as the admin runs programs, the
> daemon could write to the terminal to inject data into the admin
> processes.  You could deny this terminal access to close this hole, but
> the trade off is that you lose any early messages (error or otherwise)
> the daemon sends when you run_init.
>
>
>
>> This does, by the way, answer the question of why the redhat patch
>> that disables this behavior was either never submitted or never
>> accepted upstream.
>>
>> Though I wonder why redhat is OK with disabling this, given the ease
>> of implementing this additional security measure. I only got pulled
>> into this because the stock run_init does not properly pass status
>> codes.
>>
>> I was thinking that entire code block could go away because the way
>> the utility was worded, was that it was providing a ptty for init
>> scripts because the init scripts *needed* the ptty rather than being
>> as some value of exec STDIO filtering / FD protection / whatever.
>>
>> I was asking both gentoo and debian maintainers of this as well as
>> other random folks and nobody saw the value of this. I still have a
>> hard time wrapping my head around the problem this solves but the cost
>> of doing it this way is zero, as long as a tiny little bit of work
>> (that debian already did) to pass status codes is done.
>>
>> Which is all I wanted in the first place.
>>
>> run_init likes to clobber status codes, which breaks my puppet.
>>
>>
>> On Mon, Dec 15, 2014 at 7:55 AM, Christopher J. PeBenito
>> <cpebenito@tresys.com> wrote:
>>> On 12/15/2014 6:32 AM, eric gisse wrote:
>>>> In tracking down some related issues, the subject of the helper
>>>> program /usr/sbin/open_init_pty came up.
>>>>
>>>> This gets called by run_init as the final step for running a program
>>>> in the initrc context, like this:
>>>>
>>>> if (execvp("/usr/sbin/open_init_pty", argv)) {
>>>>   perror("execvp");
>>>>   exit(-1);
>>>> }
>>>>
>>>> The context for this problem is the discovery that open_init_pty
>>>> doesn't play well with others by refusing to pass along return codes.
>>>> Eg, run_init from stock will always return 0.
>>>>
>>>> Debian fixes this problem by fixing open_init_pty to return status
>>>> codes, redhat bypasses it in favor of execvp(), and gentoo uses stock
>>>> and is evaluating its' options.
>>>>
>>>> What I'm trying to figure out is, is the function of open_init_pty in
>>>> the general sense.
>>>>
>>>> Init scripts don't generally get a pty, so I don't understand the
>>>> necessity and hope someone here can shed a little light on this.
>>> Most daemons will print early error messages before reopening their
>>> stdin/out/err to /dev/null.  The purpose of open_init_pty is to provide
>>> an isolated stdin/out/err for the init scripts and daemons.  Without it,
>>> we'd have to allow all daemons to read/write sysadm/unconfined
>>> terminals, which opens those highly-privileged users to attack.
>
Luckily with systemd we no longer have to worry about daemons gaining
access to admin terminals, since they are no longer children of the
admin process.