[chef] Re: Re: Re: Re: Re: Re: Running package install with sudo


Chronological Thread 
  • From: Tristan Sloughter < >
  • To:
  • Subject: [chef] Re: Re: Re: Re: Re: Re: Running package install with sudo
  • Date: Wed, 8 Dec 2010 11:21:13 -0600
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=IZE5NqbtcPzGM+WXxuSleRsEW31yK0hg0M73fk/vdKeqaZPzjFv/neyHgav9Tmb3wu qfdEuqe9jHQ4XE/obIocSdZard2GbCuUFK0ThTx/NUJbW78n1CKTbBGGkBbJIJKWHgin GKYYeCo8nXAnQ8cPh2tE7WOB7Ql/YTdpjeKfk=

Yeah, it is not secure. I wish there was a way to make this more secure, but none of the options seemed to give that.

My plan to is to soon remove the need for this by having the software that configures the OS and users to also install this necessary RPM.

Tristan

On Wed, Dec 8, 2010 at 11:18 AM, Daniel DeLeo < "> > wrote:
For the sake of argument, what's to stop a bad guy from installing a
setuid shell (or whatever) via yum/rpm if he gains access to your
package system?

Adding a privilege separation/non-root mode to Chef is something I
think about from time to time, but every design I come up with has a
trivial workaround for the attacker.

Dan DeLeo

On Wed, Dec 8, 2010 at 2:12 AM, Christian Requena < "> > wrote:
> I don't think the approach with the groups will work. You need sudo to run
> rpm/yum, because of the rpm db.
>
> --CR
>
> On 12/08/2010 09:57 AM, Dreamcat4 wrote:
>>
>> Another thing you can try is to make /usr group writable to the
>> "admin" group. And add your user on the admin group. Then installing
>> packages without sudo. The initial chowning of directories will
>> require sudo however.
>>
>> On Wed, Dec 8, 2010 at 7:26 AM, Noah Kantrowitz< "> >
>>  wrote:
>>
>>>
>>> On Dec 7, 2010, at 3:08 PM, Christian Requena wrote:
>>>
>>>
>>>>
>>>> Hi,
>>>>
>>>> you can define your commands freely.
>>>>
>>>> Example for tomcat.
>>>>
>>>> Define what do you want to do (i.e. in an attribute file):
>>>>
>>>>
>>>>>
>>>>> # start the service
>>>>> default[:tomcat][:start]= (platform == 'windows') ?
>>>>> 'C:\Applications\tomcat\bin\catalina.sh start' : \
>>>>>                                                    "sudo service tomcat
>>>>> start"
>>>>> # stop the service
>>>>> default[:tomcat][:stop]= (platform == 'windows') ?
>>>>> 'C:\Applications\tomcat\bin\catalina.sh stop' : \
>>>>>                                                   "sudo service tomcat
>>>>> stop"
>>>>> #
>>>>> # get service status. TODO: windows!?
>>>>> default[:tomcat][:status]="sudo service tomcat status"
>>>>>
>>>>
>>>> Overwrite the start,stop,... commands in your recipe:
>>>>
>>>>
>>>>>
>>>>> ...
>>>>> service "tomcat" do
>>>>>  action :nothing
>>>>>  supports :start =>  true, :stop =>  true, :restart =>  true, :status
>>>>> =>
>>>>> false
>>>>>  start_command node[:tomcat][:start]
>>>>>  stop_command node[:tomcat][:stop]
>>>>>  status_command node[:tomcat][:status]
>>>>>  restart_command "#{node[:tomcat][:stop]}&&  #{node[:tomcat][:start]}"
>>>>> end
>>>>> ...
>>>>>
>>>
>>> This is specific to the service resource, but you could certainly build
>>> your
>>> own provider (which would be 99% identical to the existing RPM provider)
>>> which uses sudo in the command.
>>>
>>> --Noah
>>>
>>>
>>>
>
>




Archive powered by MHonArc 2.6.16.

§