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

Re: apt as a user



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?
>
>
> 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: