Re: What is the correct way to set owner to package's files?
On Wed, 30 Dec 2015 13:34:29 +0300
Dmitrii Kashin <d.kashin@solarsecurity.ru> wrote:
> I didn't know where to put this question. It's not only
> debian-specific, but it concerns packaging in common.
>
> Our company is distributing some software splitted into packages (deb
> and rpm). Almost all files are installed into /opt/<prefix> and
> specifically all of them must be owned by some user <user>.
>
> My duty is to set up packaging of them all. And I have a problem:
> I'm using chroot environments to build out software, build process run
> under the root user and therefore all the files in /opt/<prefix> are
> owned by root. I need them to be owned by <user>.
Do you *really* need this?
I mean, the files of a package can be classified as "static" and
"dynamic" or "volatile". Static files are what the package contains
and installs onto the file system. They should naturally be owned by
root because this prevents them from tampering by unprivileged users.
On the other hand, the files the programs of the package create
themselves, are naturally owned by the specific user usually created by
the package's preinst/postinst script; this user is usually denied
login to the system.
Yet some other files might need special access. For instance,
configuration files might contain security-sensitive information (like
database user credentials), and if your package provides programs which
run with credentials of unprivileged users (a typical case with
daemons), these programs might need to access such files using their
own (non-root) credentials. In this case, it's sensible to still make
these files owned by root and a special group which has read-only
access and includes the user which credentials is used to run those
daemons.
Hence I urge you to reconsider your approach, categorize the files your
project installs into the groups I outlined above and keep as tight
permissions as possible. To reiterate, suppose that the files of the
Apache web server would be owned by www-data, the standard Debian system
user to run web server software. Now should any exploit of any
dynamic *web site* run by Apache (let me repeat: not even a hole in the
server itself) allow an attacker to execute a script on your server (be
it PHP, Python or whatever else the site's engine is written in), they
will be able to overwrite /usr/sbin/apache unless it happens to be on a
filesystem mounted read-only. No kernel working exploit is needed at
all. Local users which will happen to own certain program files which
could also be run by administrators (with root credentials) might craft
a number of interesting attacks as well.
All in all, I'm afraid you might be facing a case of the so-called
"XY problem" [1] -- trying to find help for crafting a soluton to a
wrong problem.
1. http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem
Reply to: