How to achieve privilege separation between multiple services (e.g. uwsgi) proxied by nginx?Does systemd...
Unreliable Magic - Is it worth it?
Why, precisely, is argon used in neutrino experiments?
How do scammers retract money, while you can’t?
India just shot down a satellite from the ground. At what altitude range is the resulting debris field?
What does 算不上 mean in 算不上太美好的日子?
Escape a backup date in a file name
Pole-zeros of a real-valued causal FIR system
Return the Closest Prime Number
Is there a korbon needed for conversion?
Is this apparent Class Action settlement a spam message?
when is out of tune ok?
Do sorcerers' Subtle Spells require a skill check to be unseen?
What can we do to stop prior company from asking us questions?
Class Action - which options I have?
Applicability of Single Responsibility Principle
Go Pregnant or Go Home
Integer addition + constant, is it a group?
How does the UK government determine the size of a mandate?
How to run a prison with the smallest amount of guards?
Method to test if a number is a perfect power?
Lay out the Carpet
What is the best translation for "slot" in the context of multiplayer video games?
Flow chart document symbol
Is HostGator storing my password in plaintext?
How to achieve privilege separation between multiple services (e.g. uwsgi) proxied by nginx?
Does systemd allow for functionality like authbind? Where you can allow a non-root user to bind to a priv port?ACL users to change write permissionsHow can I see which flags Nginx was compiled with?Nginx, uWSGI, Python, users, groups and permissions. Questions about securityDoes uwsgi workers share a common memory ? [ With Nginx ]Samba Ignoring POSIX ACLsHow can I grant different rights to a group of users based on the ownership of a fileuwsgi configuration with Nginx, with python scripts as cgi - 502 Bad GatewayShare Permissions: Why can a group access a share, but not members of that group (Windows Server Environment)?How can I configure nginx with multiple uwsgi vassals (with websockets) in emperor mode?PHP-FPM socket reuse causes errors
One website I maintain is composed of multiple local applications, all proxied by the same nginx instance. Each application is running under its own user and exposing a unix socket writable by the web server group www-data.
All application users are part of the www-data group, so they can chown their sockets. How can i improve my setup, so that a vulnerability in one application can no longer be used to attempt further privilege escalation through direct connections to the other sockets?
My previous solution: Create a new group for every user and add the web server to all those. This solution is less preferable, as it complicates adding/removing applications & requires a hard restart of the web server to update groups.
nginx file-permissions groups uwsgi
asked Aug 9 '15 at 18:49
anxanx
1,8261821
add a comment |
One website I maintain is composed of multiple local applications, all proxied by the same nginx instance. Each application is running under its own user and exposing a unix socket writable by the web server group www-data.
All application users are part of the www-data group, so they can chown their sockets. How can i improve my setup, so that a vulnerability in one application can no longer be used to attempt further privilege escalation through direct connections to the other sockets?
My previous solution: Create a new group for every user and add the web server to all those. This solution is less preferable, as it complicates adding/removing applications & requires a hard restart of the web server to update groups.
nginx file-permissions groups uwsgi
asked Aug 9 '15 at 18:49
anxanx
1,8261821
If it is writable by the user, andwww-data, and nobody else, what is the problem?
– Michael Hampton♦
Aug 9 '15 at 18:57
@MichaelHampton because all users are in that same group.. they could search other user's sockets via netstat and start shenanigans.
– anx
Aug 9 '15 at 19:00
add a comment |
One website I maintain is composed of multiple local applications, all proxied by the same nginx instance. Each application is running under its own user and exposing a unix socket writable by the web server group www-data.
All application users are part of the www-data group, so they can chown their sockets. How can i improve my setup, so that a vulnerability in one application can no longer be used to attempt further privilege escalation through direct connections to the other sockets?
My previous solution: Create a new group for every user and add the web server to all those. This solution is less preferable, as it complicates adding/removing applications & requires a hard restart of the web server to update groups.
nginx file-permissions groups uwsgi
asked Aug 9 '15 at 18:49
anxanx
1,8261821
One website I maintain is composed of multiple local applications, all proxied by the same nginx instance. Each application is running under its own user and exposing a unix socket writable by the web server group www-data.
All application users are part of the www-data group, so they can chown their sockets. How can i improve my setup, so that a vulnerability in one application can no longer be used to attempt further privilege escalation through direct connections to the other sockets?
My previous solution: Create a new group for every user and add the web server to all those. This solution is less preferable, as it complicates adding/removing applications & requires a hard restart of the web server to update groups.
nginx file-permissions groups uwsgi
nginx file-permissions groups uwsgi
asked Aug 9 '15 at 18:49
anxanx
1,8261821
asked Aug 9 '15 at 18:49
anxanx
1,8261821
edited 5 mins ago
anx
asked Aug 9 '15 at 18:49
anxanx
1,8261821
asked Aug 9 '15 at 18:49
anxanx
1,8261821
asked Aug 9 '15 at 18:49
anxanx
1,8261821
1,8261821
If it is writable by the user, andwww-data, and nobody else, what is the problem?
– Michael Hampton♦
Aug 9 '15 at 18:57
@MichaelHampton because all users are in that same group.. they could search other user's sockets via netstat and start shenanigans.
– anx
Aug 9 '15 at 19:00
add a comment |
If it is writable by the user, andwww-data, and nobody else, what is the problem?
– Michael Hampton♦
Aug 9 '15 at 18:57
@MichaelHampton because all users are in that same group.. they could search other user's sockets via netstat and start shenanigans.
– anx
Aug 9 '15 at 19:00
If it is writable by the user, and
www-data, and nobody else, what is the problem?– Michael Hampton♦
Aug 9 '15 at 18:57
If it is writable by the user, and
www-data, and nobody else, what is the problem?– Michael Hampton♦
Aug 9 '15 at 18:57
@MichaelHampton because all users are in that same group.. they could search other user's sockets via netstat and start shenanigans.
– anx
Aug 9 '15 at 19:00
@MichaelHampton because all users are in that same group.. they could search other user's sockets via netstat and start shenanigans.
– anx
Aug 9 '15 at 19:00
add a comment |
1 Answer
1
active
oldest
votes
Similar to how services can inherit privileged ports from systemd, they can receive access to local sockets they would otherwise have no permission to open.
Systemd creates the unix socket and passes only the file description to the service - this way, the service does not need access permissions on the socket file.
Setup the socket using /etc/systemd/system/example.socket like this: (read man systemd.socket)
[Unit]
PartOf=example.service
[Socket]
SocketUser=www-data
SocketMode=0600
ListenStream=%t/example.sock
And use that socket in /etc/systemd/system/example.service like this: (read man systemd.unit)
[Unit]
Requires=example.socket
After=example.socket
[Service]
User=example
WorkingDirectory=~
ExecStart=/usr/bin/uwsgi --uwsgi-socket=fd://3 --opt2 --opt3 ..
Note that many programs, including uwsgi, do understand LISTEN_FDS in their environment, so hard-coding file descriptor 3 is often unnecessary.
Apply and start the unit using:
systemctl dameon-reload
systemctl start example.service
If a service account then attempts to open the socket of another service, he will not succeed - the sockets are owned and exclusively readable by www-data (i.e. only the web server running under that user can access them).
answered 33 mins ago
anxanx
1,8261821
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f712947%2fhow-to-achieve-privilege-separation-between-multiple-services-e-g-uwsgi-proxi%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Similar to how services can inherit privileged ports from systemd, they can receive access to local sockets they would otherwise have no permission to open.
Systemd creates the unix socket and passes only the file description to the service - this way, the service does not need access permissions on the socket file.
Setup the socket using /etc/systemd/system/example.socket like this: (read man systemd.socket)
[Unit]
PartOf=example.service
[Socket]
SocketUser=www-data
SocketMode=0600
ListenStream=%t/example.sock
And use that socket in /etc/systemd/system/example.service like this: (read man systemd.unit)
[Unit]
Requires=example.socket
After=example.socket
[Service]
User=example
WorkingDirectory=~
ExecStart=/usr/bin/uwsgi --uwsgi-socket=fd://3 --opt2 --opt3 ..
Note that many programs, including uwsgi, do understand LISTEN_FDS in their environment, so hard-coding file descriptor 3 is often unnecessary.
Apply and start the unit using:
systemctl dameon-reload
systemctl start example.service
If a service account then attempts to open the socket of another service, he will not succeed - the sockets are owned and exclusively readable by www-data (i.e. only the web server running under that user can access them).
answered 33 mins ago
anxanx
1,8261821
add a comment |
Similar to how services can inherit privileged ports from systemd, they can receive access to local sockets they would otherwise have no permission to open.
Systemd creates the unix socket and passes only the file description to the service - this way, the service does not need access permissions on the socket file.
Setup the socket using /etc/systemd/system/example.socket like this: (read man systemd.socket)
[Unit]
PartOf=example.service
[Socket]
SocketUser=www-data
SocketMode=0600
ListenStream=%t/example.sock
And use that socket in /etc/systemd/system/example.service like this: (read man systemd.unit)
[Unit]
Requires=example.socket
After=example.socket
[Service]
User=example
WorkingDirectory=~
ExecStart=/usr/bin/uwsgi --uwsgi-socket=fd://3 --opt2 --opt3 ..
Note that many programs, including uwsgi, do understand LISTEN_FDS in their environment, so hard-coding file descriptor 3 is often unnecessary.
Apply and start the unit using:
systemctl dameon-reload
systemctl start example.service
If a service account then attempts to open the socket of another service, he will not succeed - the sockets are owned and exclusively readable by www-data (i.e. only the web server running under that user can access them).
answered 33 mins ago
anxanx
1,8261821
add a comment |
Similar to how services can inherit privileged ports from systemd, they can receive access to local sockets they would otherwise have no permission to open.
Systemd creates the unix socket and passes only the file description to the service - this way, the service does not need access permissions on the socket file.
Setup the socket using /etc/systemd/system/example.socket like this: (read man systemd.socket)
[Unit]
PartOf=example.service
[Socket]
SocketUser=www-data
SocketMode=0600
ListenStream=%t/example.sock
And use that socket in /etc/systemd/system/example.service like this: (read man systemd.unit)
[Unit]
Requires=example.socket
After=example.socket
[Service]
User=example
WorkingDirectory=~
ExecStart=/usr/bin/uwsgi --uwsgi-socket=fd://3 --opt2 --opt3 ..
Note that many programs, including uwsgi, do understand LISTEN_FDS in their environment, so hard-coding file descriptor 3 is often unnecessary.
Apply and start the unit using:
systemctl dameon-reload
systemctl start example.service
If a service account then attempts to open the socket of another service, he will not succeed - the sockets are owned and exclusively readable by www-data (i.e. only the web server running under that user can access them).
answered 33 mins ago
anxanx
1,8261821
Similar to how services can inherit privileged ports from systemd, they can receive access to local sockets they would otherwise have no permission to open.
Systemd creates the unix socket and passes only the file description to the service - this way, the service does not need access permissions on the socket file.
Setup the socket using /etc/systemd/system/example.socket like this: (read man systemd.socket)
[Unit]
PartOf=example.service
[Socket]
SocketUser=www-data
SocketMode=0600
ListenStream=%t/example.sock
And use that socket in /etc/systemd/system/example.service like this: (read man systemd.unit)
[Unit]
Requires=example.socket
After=example.socket
[Service]
User=example
WorkingDirectory=~
ExecStart=/usr/bin/uwsgi --uwsgi-socket=fd://3 --opt2 --opt3 ..
Note that many programs, including uwsgi, do understand LISTEN_FDS in their environment, so hard-coding file descriptor 3 is often unnecessary.
Apply and start the unit using:
systemctl dameon-reload
systemctl start example.service
If a service account then attempts to open the socket of another service, he will not succeed - the sockets are owned and exclusively readable by www-data (i.e. only the web server running under that user can access them).
answered 33 mins ago
anxanx
1,8261821
answered 33 mins ago
anxanx
1,8261821
answered 33 mins ago
anxanx
1,8261821
answered 33 mins ago
anxanx
1,8261821
1,8261821
add a comment |
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f712947%2fhow-to-achieve-privilege-separation-between-multiple-services-e-g-uwsgi-proxi%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
If it is writable by the user, and
www-data, and nobody else, what is the problem?– Michael Hampton♦
Aug 9 '15 at 18:57
@MichaelHampton because all users are in that same group.. they could search other user's sockets via netstat and start shenanigans.
– anx
Aug 9 '15 at 19:00