[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: apt as a user



On 2014-10-31 17:17, shawn wilson wrote:
> On Fri, Oct 31, 2014 at 12:05 PM, Mario Castelán Castro
> <marioxcc.MT@yandex.com> wrote:
>> El 31/10/14 09:29, shawn wilson escribió:
>>
>>> I'm trying to allow an apt user to run apt* commands. I've got this
>>> polkit:
>>>
>>> /etc/polkit-1/localauthority/30-site.d/10-org.com.foo.apt.pkla
>>>
>>> [Configuration]
>>> AdminIdentities=unix-user:apt
>>> Action=org.debian.apt.*
>>> ResultAny=no
>>> ResultInactive=no
>>> ResultActive=yes
>>>
>>> However when I: su - apt
>>> it looks like nothing has changed:
>>>
>>> $ apt-get update
>>> E: Could not open lock file /var/lib/apt/lists/lock - open (13:
>>> Permission denied)
>>> E: Unable to lock directory /var/lib/apt/lists/
>>> E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission
>>> denied)
>>> E: Unable to lock the administration directory (/var/lib/dpkg/), are you
>>> root?
>>>
>>> I've got aptdaemon installed. Any idea what I'm doing wrong here?

If I'm reading the description and documentation of aptdaemon right, you
need to use an aptdaemon client, which would be aptdcon in the same
package. But the fetching and installation would then be done by
aptdaemon, which would still be run as root and not the user executing
aptdcon.


>>
>> I'm not an expert in Debian package management, but I think that the error
>> is what it says, the user lacks appropriate permissions for those files and
>> directories. I recommend that you configure sudo to allow those users to
>> invoke at least apt-get. You can also use sudo to log the commands and even
>> the command line interaction. See the man page of sudo and sudoers.
>>
> Arg, I forgot to mention the reason I'm doing this:
> Right now I only allow http(s) out to repo servers on certain times
> that we do updates:
> -A FORWARD -d <dest ip> -i eth5 -p tcp -m tcp --sport 1024:65535
> --dport 80 -m time --weekdays <day> --datestop <time range> -j ACCEPT
>
> What I want is a way to limit it to a command. The only way I know how
> to do that is to specify --uid-owner in iptables
>
>> Bear in mind that users who can install and uninstall packages can make the
>> system unusable or purposely install a vulnerable package to perform
>> privilege escalation. If they can add repositories, they can easily direct
>> the package manager to a specially crafted package which will give them root
>> access without the need to exploit an existing package. If you wouldn't
>> trust root access to those users, don't give them package management
>> capabilities.
>>
> So my original thought was to use pkexec and set the user to
> /bin/false but pkexec wants to ask me for a password - since I don't
> have/know/want to use a password (all logins are ssh with keys) IDK
> that's going to work. So just a user to su into in order to run the
> command should be ok....? Security wise - I'm always open to being
> checked.
>
>


Reply to: