Re: [cobalt-users] security risk... is this normal?

[Greg Hewitt-Long <cobaltusers@xxxxxxxxxxxxxxxxxxx>]

At 11:58 AM 3/1/2004, you wrote:
> On Monday 01 March 2004 10:35 am, Dmitry Alexeyev wrote:
>
> > Since it is not setuid, where do you see security risks?
> > Look into /etc/rc.d/init.d/* - they are all 755.
> > And there's no risk
>
> Just because a distribution chooses to use insecure permissions and
> rights, doesn't mean there's no risk.
>
> There probably isn't much risk in the files in /etc/rc.d/init.d/, since
> they all run programs that once running as root can't be stopped by
> anyone but root.  But still I wouldn't set up a system that way.
>
> > rpm can only access to it's base being the root user normally...
>
> RPMs don't have any such limitation; generally the programs being
> installed require RPM to be run as root, but RPM doesn't care.
>
> Generally if you're not root you can only uninstall something you've
> installed yourself, but again, that depends on permissions and rights.



my point exactly.

> > > ps - I noticed that a third-party installation of phpMyAdmin from
> > > NuOnce was CORRECTLY set as 700 and root/root owner/group - thereby
> > > removing the possibility that a non-permissioned user could cause
> > > any problem.
>
> And certainly you can change the other uninstallers to have the same
> rights/privileges/owner.


yep - I did that.


> > rpm -qa gives you installed rpm list
> > rpm -e could delete any package.
>
> Unless run by root, rpm -e can only delete a package installed by the
> user who installed it.
>
> > Why setting it to 700? Well, someone may see what rpm package is it,
> > and so what?
>
> Why set what to 700?  The RPM executable?  Actually, on a RaQ that's
> probably a good idea.


That is a good idea.


> The uninstallers.  Sure.  No problem.  Might not be much extra security,
> but it doesn't cause problems.


As Jeff pointed out, the uninstaller scripts.  The potential problem I see 
is uninstaller scripts with rm commands in them - these are currently able 
to be run by any shell enabled user - while package default installers 
*SHOULD* set their data folders to be correctly permissioned to prevent 
accidental removal but just anyone, it doesn't mean they are, or remain 
that way.  Running the script by a non-permissioned user should error all 
the way - at least you HOPE it does.  What if the rm has a -r and you have 
a couple of files in there with incorrectly set permission, either by 
installer screw up,or subsequent admin mis-hap.

I'm in the process of training another staff member to admin these boxes - 
I remember nearly 20 years ago screwing up a box completely BY ACCIDENT - I 
don't want that to happen again on one of our boxes!

> > On the other hand all Raq stuff is so 'modern', so anybody
> > expierenced a bit with a shell or php might get root in a couple of
> > minutes on any raq. It's really easy.
> > Restrict shell access!
>
> While I agree with you here, there's certainly nothing wrong with
> keeping a system as secure as possible.


While I agree that there are many clients out there who should not have 
shell access, there are others who demand it.  I'm not doing away with 
shell access - I am trying to lock down my permissions without changing the 
business model.


> > Restrict PHP & CGI!
>
> ...to the greatest extent possible without risking losing all your
> clients.
>
> Jeff