Mirror not updating

[Alessandro Doro]

On Thu, Jul 09, 2009 at 08:45:26PM -0400, Daenyth Blank wrote:
> On Thu, Jul 9, 2009 at 20:25, Alessandro Doro<ordo.ad@...> wrote:
> > A simple workaround could be a "sudo  -k" after each sudo invocation in
> > the makepkg script.
> >
>
> I don't think there should be any such behavior added. All we do is
> follow the settings the user has established -- no more and no less.
> Let's not have our tools start second-guessing the users. We should
> always start with the assumption that the user is competant.

Competent and informed: I don't see a warning about potential¹ security
issue in makepkg(8).
Moreover the description of the '-s' option doesn't talk about the way
root privileges are acquired².
At least the sudo prompt should be customized, or is the user supposed
to read the source (read: the user should not second-guess the tool)?
Anyway I'm for discouraging the use of sudo for admnistrative tasks.

bye

¹ Really theoretical, assuming that the user:
  · read the PKGBUILD,
  · trust the package source.

² Ok, ok... we all know it is obviuos.

[James Rayner-2]

On Fri, Jul 10, 2009 at 11:39 AM, Alessandro Doro<ordo.ad@...> wrote:
> ¹ Really theoretical, assuming that the user:
>  · read the PKGBUILD,
>  · trust the package source.

Yeah... I think I'd be somewhat suspicious if I saw a PKGBUILD calling sudo.

sudo -k wouldn't be very effective either. What if I run sudo
elsewhere on my system during the build process, the hole is open
again.

As long as you're running an untrusted script on your system, there's
infinitely many other possibilities. An rm -rf ~/* is pretty damaging
and doesn't need sudo.

Allesandro is spot on.

James

[Thomas Bächler-2]

Aaron Griffin schrieb:
>> I agree. The question is not about makepkg security, but about sudo
>> security. And frankly, sudo is a security desaster in its default
>> configuration.
>
> Any suggestions for changing / shipping a better default config file?
> I know little about the security implications of this, but I think we
> should ship a decent default if possible.

Our policy is usually to ship whatever upstream ships. IMO, a good
default would be to set sudo to require the root password (not the user
password) and not cache any passwords at all.

Also, I think instead of using sudo in makepkg, we should use su by
default (with an option to enable sudo). su always has a good default
configuration requiring the root password (it's also possible to set it
to allow password-less su in the pam configuration, but everyone who
does that is crazy anyway).

[Aaron Griffin]

On Fri, Jul 10, 2009 at 3:01 AM, Thomas Bächler<thomas@...> wrote:

> Aaron Griffin schrieb:
>>>
>>> I agree. The question is not about makepkg security, but about sudo
>>> security. And frankly, sudo is a security desaster in its default
>>> configuration.
>>
>> Any suggestions for changing / shipping a better default config file?
>> I know little about the security implications of this, but I think we
>> should ship a decent default if possible.
>
> Our policy is usually to ship whatever upstream ships.

Not always - there has always been the "sane defaults" clause. We ship
lots of config files and additional config files that upstream
packages do not contain. Shipping and changing config files has
nothing to do with "vanilla" because it's how the application was
intended to work.

Besides that, I like your ideas here... but perhaps we should move
them to the pacman-dev list?

[Daenyth Blank]

On Fri, Jul 10, 2009 at 04:01, Thomas Bächler<thomas@...> wrote:
> Our policy is usually to ship whatever upstream ships. IMO, a good default
> would be to set sudo to require the root password (not the user password)
> and not cache any passwords at all.
I strongly disagree with this. That's a disaster on a multiuser
system. It purposely does *not* require the root password so that a
user is responsible for only their own password, and so that you can
limit their usage of superuser powers to only specific commands.

> Also, I think instead of using sudo in makepkg, we should use su by default
> (with an option to enable sudo). su always has a good default configuration
> requiring the root password (it's also possible to set it to allow
> password-less su in the pam configuration, but everyone who does that is
> crazy anyway).
>
I don't think that should really be the default, personally. Sudo has
been fine, I don't know of anyone having an actual issue with misuse.

[Allan McRae-3]

Aaron Griffin wrote:

> On Fri, Jul 10, 2009 at 3:01 AM, Thomas Bächler<thomas@...> wrote:
>  
>> Aaron Griffin schrieb:
>>    
>>>> I agree. The question is not about makepkg security, but about sudo
>>>> security. And frankly, sudo is a security desaster in its default
>>>> configuration.
>>>>        
>>> Any suggestions for changing / shipping a better default config file?
>>> I know little about the security implications of this, but I think we
>>> should ship a decent default if possible.
>>>      
>> Our policy is usually to ship whatever upstream ships.
>>    
>
> Not always - there has always been the "sane defaults" clause. We ship
> lots of config files and additional config files that upstream
> packages do not contain. Shipping and changing config files has
> nothing to do with "vanilla" because it's how the application was
> intended to work.
>  

The default sudo config is quite sane and secure...  I believe it gives
no-one rights to use sudo.   Any lessening of security is purely the
administrators responsibility.

Allan

[Square]

On Fri, Jul 10, 2009 at 12:00:47PM -0400, Daenyth Blank wrote:
> I don't think that should really be the default, personally. Sudo has
> been fine, I don't know of anyone having an actual issue with misuse.

I agree with the idea that it should be up to the user to secure their
system. I went ahead and made sudo timeout much quicker after realizing
this. Your point, however, that people haven't run into any misuse is a
double-edged sword.

For one, it's great that we need not worry considering the community is
very friendly rather than malicious. Then again, ignorance could be
harmful if someone were to decide to create malicious content.

I don't see a need to change anything as it is unless the changes
provided are optional.

[clemens fischer-3]

On Thu-2009/07/09-19:17 Gerhard Brauer wrote:

> for arch in ${ARCHES}; do
>    for repo in ${REPOS}; do
>        echo -e -n "$arch-$repo:\t"
>        date +"%x %X" -u -d @$(wget -q -O - $1/$repo/os/$arch/lastsync)
>    done
> done

please don't post anything like this:  apart from being barely
comprehendable, it is _unsafe_!  you are using _outside info_ in a shell
script _without validation_!  it poses the risk of privilege escalation!

and don't say security issues should be handled by remote admins!

how about:

  # uses bash features
  shopt -s extglob
  iam="${0##*/}"
  tmp=""
  ex=0
  tmpfile="${TMPDIR:-/tmp}/${iam}.tmp"
  wget="/usr/bin/wget -q"
  # risk: race
  rm -rf "${tmpfile}" && touch "${tmpfile}" || exit 9
  for arch in ${ARCHES}; do
     for repo in ${REPOS}; do
         # risk: backquote execution, better use unpriv script
         ${wget} -O "${tmpfile}" "${1}/${repo}/os/${arch}/lastsync" || {
            ex=$?
            echo "${iam}: $1/${repo}/os/$arch/lastsync wget exits: ${ex}"
            continue
         }
         tmp="$(< ${tmpfile})"
         # remove all punctuation characters, check for numbers
         tmp="${tmp//[[:punct:]]}"
         case ".${tmp}" in
            .+([[:digit:]])) ;; # ok
            *)
                echo "${iam}: $1/${repo}/os/$arch/lastsync not number: ${tmp}"
                continue
                ;;
        esac
        echo -e -n "${arch}-${repo}:\t"
        date +"%x %X" -u -d "@${tmp}"
     done
  done

not much longer, but a little safer.  the least one should do in this
situation.


clemens