[sbopkg-discuss] Re: Package ownership

Chess Griffin chess at chessgriffin.com
Wed Feb 11 03:24:32 UTC 2009


* Phillip Warner <phillip.c.warner at gmail.com> [2009-02-10 21:15:06]:

> 
> On 2/10/09, T2F <bkirkp at gmail.com> wrote:
> >
> > Can someone explain to me why sbopkg insists that the package belong
> > to root:root? I keep my sandbox with the rest of my data on a server
> > partition where the files are owned by bill:data & permissioned 664. I
> > have an hourly cron job that sees to the proper permissions. If I
> > build a package & install it immediately, I have no problems, but if I
> > go back later, for example to install it on my laptop, I have to
> > install from the command line. installpkg has no problems with
> > ownership, why should sbopkg?
> > Regards,
> > Bill
> 
> Not checking for root:root perms opens up a package spoofing
> vunerability in sbopkg.  If this doesn't bother people perhaps the
> check could be allowed to be turned off with a config switch.  Here is
> a portion of the email I previously sent Chess that describes the
> vunerability:
> 
> ===========
> in brief, sbopkg needs to make sure packages in $OUTPUT are owned
> root:root before even offering to install.  If $OUTPUT is world
> writable (such as /tmp) then normal user can make a fake or malicious
> package that makes sbopkg thinks it can install.
> 
> ---- How to spoof SBo packages ----
> simply make sure the package
>   name starts with the PRGNAM (the name can be longer than PRGNAM though)
>   has the corresponding VERSION, BUILDNUM, and TAG
> this info can easily be found in the local or online repo
> 
> Now when the admin views an entry for a SlackBuild they will have the
> option to install this fake package!
> 
> While this may not fool the admin who knows they did not build a
> package, it might be easy to fool an admin by making a fake package
> corresponding to a SBo package that IS in OUTPUT.
> Simply change the ARCH, or if the admin made a custom version or tag,
> then the regular name might work.
> 
> SBo package spoofing could be defeated by making sure:
> 1) that your $OUTPUT is a folder only root has access to
> 2) sbopkg enforces that packages to install have root:root ownership
> ============
> 

Although, after further reflection and discussion with others, I am not
sure this is really an sbopkg issue.  All sbopkg does is run the
SlackBuild and then execute 'installpkg' on what is dropped into /tmp.
It would seem to me that the same spoof could happen by a root user
running an SBo SlackBuild outside, which saves a package to /tmp,
another user coming along and makes a fake package and overwrites the
one in /tmp, which root then installs at a later date.

It seems that all of these spoofs involving the SlackBuild, the .info
file, and the resulting package are inherent in the SBo and SlackBuild
system, and not sbopkg-specific.

-- 
Chess Griffin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://sbopkg.org/pipermail/sbopkg-users/attachments/20090210/93cbcc2e/attachment.sig>


More information about the sbopkg-users mailing list