Re: World writable pid and lock files.
On 05/11/11 13:23, Henrique de Moraes Holschuh wrote:
> On Wed, 11 May 2011, Mike Mestnik wrote:
>> On 05/11/11 01:37, helpermn wrote:
>>> On Tue, 10 May 2011, Henrique de Moraes Holschuh <hmh@debian.org> wrote:
>>>> On Tue, 10 May 2011, helpermn wrote:
>>>>> I imagine why files listed below have 666 file mode bits set:
>>>>> /var/run/checkers.pid
>>>>> /var/run/vrrp.pid
>>>>> /var/run/keepalived.pid
>>>>> /var/run/starter.pid
>>>>> /var/lock/subsys/ipsec
>>>>> ....
>>>> You could get the initscripts to send signals to any PID you want, so
>>>> yes, it is a nasty security issue.
>>>>
>> It should be mandatory for initscripts to verify the pid is indeed an
>> instance of there daemon.
>>
>> ...as well as correcting the world writable bit.
> These things are to be fixed properly. You need to actually create the
> pidfile securely in the first place. Which means using O_CREAT|O_EXCL,
> often together with O_CLOEXEC, etc.
>
> Most initscripts will make sure they only signal processes that match the
> inode in the path they expect the process to be. Refer to the --exec option
This breaks on updates, where the exec is replaced and the inode number
changes. The esiest is to just check the cmd line of the process, but
an inspection of the contents of the exec is not out of the question.
> of start-stop-daemon(8). However, this cannot be done in any of the more
> important daemons where you do not stop-before-upgrading, but rather
> restart-after-upgrading.
>
Reply to: