Re: [gentoo-user] portage directory ownerships?

[Fernando Rodriguez]

On Wednesday, September 16, 2015 8:01:56 AM Alan McKinnon wrote:
> On 16/09/2015 00:36, Fernando Rodriguez wrote:
> > On Tuesday, September 15, 2015 10:25:15 PM Alan McKinnon wrote:
> >> On 15/09/2015 22:09, james wrote:
> >>> Hello,
> >>>
> >>> So looking at /etc/portage/repos.conf, it seems root.root owns these
> >>> files; shouldn't it be portage.portage? and /usr/portage
> >>>
> >>> That got me thinking. Everywhere that portage operates or owns
> >>> things, should the ownership not be portage.portage
> >>> and what would the typical permissions be?
> >>
> >> Here, all of /etc/portage is root:root
> >> The tree and all overlays are portage:portage
> >>
> >> You can make a local overlay owned by user you want, stuff you hack away
> >> at yourself should probably be james:james or james:users
> >>
> >> Typically, permissions in /etc/portage are the usual 755 for dirs and
> >> 644 for files
> >>
> >> I set overlays and the tree to be 2775 for dirs and 664 for files
> >>
> >>>
> >>> Is there a master list I can look at? Surely root not own all
> >>> these dirs, like /usr/portage/* ? My /usr/portage is root.root
> >>> and 755 on permissions, is that right?
> >>
> >> Permissions should be what YOU need them to be on your computer. There's
> >> a default, it's what portage makes them when you install stuff
> >>
> >>>
> >>> If so, why?
> >>
> >> Only root should change the master config files in /etc, just like in
> >> all other apps
> >> IIRC emerge can drop privs to a user account, if that user is portage
> >> then portage must own the files
> >
> > It is true that portage drops privileges to the portage account (unless
the 
> > ebuild has RESTRICT="userpriv" or I think FEATURES="-userpriv" on
make.conf) 
> > but it doesn't need to write to the portage tree except to the distfiles
> > directory so I don't know of any reason to have everything owned by
> > portage:portage if the perms are 755/644.
>
> portage also syncs the tree. For that it needs write perms.
>
> >
> > Mine is owned by root:root because it got borked one time after a sync so
I 
> > deleted it and copied from another box manually. The only problem I ever
had 
> > is that a fetch failed, and I just chowned the distfiles dir to
portage:portage 
> > to fix it. Only recently it was pointed to me on this list that it was
supposed 
> > to be portage:portage. I never changed it back to portage:portage but I
made a 
> > mental note not to forget about it in case of trouble, that way I'll learn
why 
> > that's the default if/when something breaks :) Besides it offers some
(limited) 
> > protection against an ebuild accidentally writing to your portage tree.
> >
> >>>
> >>> In my /usr/local/portage and it's subdirs where I hack on many
> >>> ebuild, portage.portage owns everything.....?
> >>
> >> Make your life easy, chaown that stuff to james
> >
> > I personally prefer root:root because I think it is more secure. If you
let 
> > somebody use your account even for a minute s/he could modify an ebuild
> > without a password to install whatever s/he wants next time you run an
update.
>
> I'll argue that it's less secure. Giving someone else a gap to modify
> your ebuilds when you accidentally leave the computer unlocked is a rare
> event whereas you modifying your own ebuilds like james does is a common
> event.
>
> If an overlay is root:root then he has to be root every time he works on
> it. If he then commits that rare blunder of leaving the computer
> unlocked, Murphy says he'll do it with a root shell open.

I also have the habit of never opening root shells unless absolutely necessary 
(which is next to never) and when I do I'm very conscious about it so that 
won't be a problem for me. I do a lot of ebuild hacking and that does mean I 
type my password a lot but you get used to it.

> While it is entirely possible to have a rogue colleague install a dodgy
> ebuild, that attacker would have to know exactly what to install where
> and would have to have the ebuild on hand to slip it in during the very
> few minutes available. To my eye that's a very small window of
> opportunity and needs a perfect storm to pull it off = vanishingly small
> risk

If that was my mission I just pick something that I know you run at startup 
like udev (I may pick something more trivial if possible to minimize the 
chance of you noticing). I'd bump the version and have the ebuild install my 
evil program along with it and add a few liner patch to fork() and execve() my 
program or just make my program a patch to the main prog. Then I'll put it on 
a webserver along with a script that does to work for me. Now I just need to 
run a single command to download and execute the script. 

So granted, it takes planning, and maybe some social engineering or other 
methods to get details about your system but once I get the chance it'll take 
only a few seconds and next time you update I'd have root access.

-- 
Fernando Rodriguez