On Wed, 30 Dec 2015 13:34:29 +0300 Dmitrii Kashin <d.kas...@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
