Re: [Ltib] World writable dirs in ltib

[Stuart Hughes]

Hi Svein,

As with all thing security is a balancing act between the absolute and 
preventing normal users conducting what they need to get on with.

What event are you actually worried about occurring?

The reason LTIB allows these few directories to be globally writeable is 
because it needs to:
  * Users on the same machine need to be able to download to
    the common pkgs cache
  * Users on the same machine need to be able to install updates
    to LTIB, which requires global write access to
    /opt/ltib/usr/src/rpm/* as build operations are not root.

I'm not sure how you intend to share out LTIB on a common server, but 
that may not be a great idea if you use NFS etc as this is slow and 
permissions/locking problems show up.  If you want to share your 
download area, your better off to set-up one of your download machines 
as a PPP server (http web server) and setup your .ltibrc files accordingly.

Please try to not to use emotive terms like: "awful", "to add insult to 
injury" etc as this is likely to cause offence which is not helpful.

You have some valid points, but rather than assume people have not 
considered them, ask first and explain exactly what problems you 
envisage occurring.  As I said any security policy is a balancing act.

Regards, Stuart


Svein Seldal wrote:
> Hi
>
> (@Admin: Please ignore&delete my previous post, as it was sent from 
> another account which isn't subscribing to this list.)
>
> The LPP directory, among other directories in /opt/freescale/ltib, is
> set world writable by the ltib script. This is by many considered a
> security offense as everyone (even guest or any least-privileged users)
> have write access to these directories.
>
> I'm about to deploy ltib on a common shared build server, where world
> writable dirs is not permissible. I could, of course, just alter the
> permission on the dirs locally, but to add insult to injury ltib
> actually checks that it is world writeable and refuses to continue
> without it.
>
> My recommendation is to take away those malicious chmod's from the
> rpm-fs install script, and do away with the awful 777 check in ltib.
> IMHO it is the sysop/user's responsibility to set permissions/ownerships
> policy and enforce security, not the script.
>
> I've attached a proposal to a fix. It removes the chmod 777 in
> rpm-fs*.spec and rather uses the compiling user's name as owner for the
> given directories. This will ensure that ltib --hostcf works seamlessly
>   for single user machines.
>
> For those of us on a multi user machine, the other part of the attached
> patch (ltib) will now fail unless the (rw) permissions are set right,
> but it won't try to fix it. Any awake sysops will of course catch this
> failure and set the correct permissions manually.
>
> PS! I'm not sure of which macros/variables that are available in the
> %Files section of the spec-file. Thus my patch hardcodes the location
> for ltib/pkgs. Please feel free to find another more correct method.
>
>
> - Svein
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> LTIB home page: http://ltib.org
>
> Ltib mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/ltib