[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