Allow non-root process to access all home directories without compromising security?

Clash Royale CLAN TAG#URR8PPP
Any ideas how to allow one non-root process to access (read&write) all home directories without compromising security? Normal users should not have access to each other's home directories.
All ideas are welcome, even crazy ones (nfs&kerberos setups?) :)
I basically need to create web interface for user home directories, where the non-root process is the web server process.
New files should have the home directory user as the owner. Is this even possible?
permissions security users
add a comment |
Any ideas how to allow one non-root process to access (read&write) all home directories without compromising security? Normal users should not have access to each other's home directories.
All ideas are welcome, even crazy ones (nfs&kerberos setups?) :)
I basically need to create web interface for user home directories, where the non-root process is the web server process.
New files should have the home directory user as the owner. Is this even possible?
permissions security users
add a comment |
Any ideas how to allow one non-root process to access (read&write) all home directories without compromising security? Normal users should not have access to each other's home directories.
All ideas are welcome, even crazy ones (nfs&kerberos setups?) :)
I basically need to create web interface for user home directories, where the non-root process is the web server process.
New files should have the home directory user as the owner. Is this even possible?
permissions security users
Any ideas how to allow one non-root process to access (read&write) all home directories without compromising security? Normal users should not have access to each other's home directories.
All ideas are welcome, even crazy ones (nfs&kerberos setups?) :)
I basically need to create web interface for user home directories, where the non-root process is the web server process.
New files should have the home directory user as the owner. Is this even possible?
permissions security users
permissions security users
edited Feb 28 '12 at 15:21
rahmu
10.3k1969110
10.3k1969110
asked Feb 28 '12 at 15:05
EpeliEpeli
1064
1064
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
We're going to need more info if you are looking for a complete answer. From what I understood, you may want to look into Access Control List. It is supported by many Unices and will give you better control over what user gets access to which file.
Use with care and try it in a VM first if you're not 100% comfortable.
add a comment |
I guess the difficulty is that home directories are not publicly executable in your environment.
You can put an access control list on all home directories that gives a particular user or group execution permission to the directory. The web server will then potentially be able to access any file in users' home directories, which may provide ways to escalate privileges (at least, this will broaden the impact of a local file access vulnerability). For example, under Solaris or Linux, make sure the home filesystem is mounted with the acl option, and run
setfacl -m user:www-data:x /home/*
(integrate that into your account creation setup). Then tell your users that their ~/public_html directory must be readable by the www-data user; they can run this command:
setfacl -R -m default:user:www-data:rx ~/public_html
setfacl -R -m user:www-data:rx ~/public_html
Another possibility is to mount all the users' public_html directories in a separate place on the filesystem. This approach has the advantage that the permissions on the home directories won't matter; it even allows the web server to run chroooted. Under Linux, you can do this for a home directory:
mount --bind /home/joe/public_html /srv/homepages/joe
The public_html directory and its contents still need to be made accessible to www-data.
A variant on the Linux bind mount method uses the bindfs filesystem. This method works on any OS that supports bindfs (which is most unices) and does not require any ACL settings, at the cost that any file under public_html will be made available for reading by the web server.
bindfs -u www-data -p 500 /home/joe/public_html /srv/homepages/joe
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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%2funix.stackexchange.com%2fquestions%2f32950%2fallow-non-root-process-to-access-all-home-directories-without-compromising-secur%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
We're going to need more info if you are looking for a complete answer. From what I understood, you may want to look into Access Control List. It is supported by many Unices and will give you better control over what user gets access to which file.
Use with care and try it in a VM first if you're not 100% comfortable.
add a comment |
We're going to need more info if you are looking for a complete answer. From what I understood, you may want to look into Access Control List. It is supported by many Unices and will give you better control over what user gets access to which file.
Use with care and try it in a VM first if you're not 100% comfortable.
add a comment |
We're going to need more info if you are looking for a complete answer. From what I understood, you may want to look into Access Control List. It is supported by many Unices and will give you better control over what user gets access to which file.
Use with care and try it in a VM first if you're not 100% comfortable.
We're going to need more info if you are looking for a complete answer. From what I understood, you may want to look into Access Control List. It is supported by many Unices and will give you better control over what user gets access to which file.
Use with care and try it in a VM first if you're not 100% comfortable.
answered Feb 28 '12 at 15:11
rahmurahmu
10.3k1969110
10.3k1969110
add a comment |
add a comment |
I guess the difficulty is that home directories are not publicly executable in your environment.
You can put an access control list on all home directories that gives a particular user or group execution permission to the directory. The web server will then potentially be able to access any file in users' home directories, which may provide ways to escalate privileges (at least, this will broaden the impact of a local file access vulnerability). For example, under Solaris or Linux, make sure the home filesystem is mounted with the acl option, and run
setfacl -m user:www-data:x /home/*
(integrate that into your account creation setup). Then tell your users that their ~/public_html directory must be readable by the www-data user; they can run this command:
setfacl -R -m default:user:www-data:rx ~/public_html
setfacl -R -m user:www-data:rx ~/public_html
Another possibility is to mount all the users' public_html directories in a separate place on the filesystem. This approach has the advantage that the permissions on the home directories won't matter; it even allows the web server to run chroooted. Under Linux, you can do this for a home directory:
mount --bind /home/joe/public_html /srv/homepages/joe
The public_html directory and its contents still need to be made accessible to www-data.
A variant on the Linux bind mount method uses the bindfs filesystem. This method works on any OS that supports bindfs (which is most unices) and does not require any ACL settings, at the cost that any file under public_html will be made available for reading by the web server.
bindfs -u www-data -p 500 /home/joe/public_html /srv/homepages/joe
add a comment |
I guess the difficulty is that home directories are not publicly executable in your environment.
You can put an access control list on all home directories that gives a particular user or group execution permission to the directory. The web server will then potentially be able to access any file in users' home directories, which may provide ways to escalate privileges (at least, this will broaden the impact of a local file access vulnerability). For example, under Solaris or Linux, make sure the home filesystem is mounted with the acl option, and run
setfacl -m user:www-data:x /home/*
(integrate that into your account creation setup). Then tell your users that their ~/public_html directory must be readable by the www-data user; they can run this command:
setfacl -R -m default:user:www-data:rx ~/public_html
setfacl -R -m user:www-data:rx ~/public_html
Another possibility is to mount all the users' public_html directories in a separate place on the filesystem. This approach has the advantage that the permissions on the home directories won't matter; it even allows the web server to run chroooted. Under Linux, you can do this for a home directory:
mount --bind /home/joe/public_html /srv/homepages/joe
The public_html directory and its contents still need to be made accessible to www-data.
A variant on the Linux bind mount method uses the bindfs filesystem. This method works on any OS that supports bindfs (which is most unices) and does not require any ACL settings, at the cost that any file under public_html will be made available for reading by the web server.
bindfs -u www-data -p 500 /home/joe/public_html /srv/homepages/joe
add a comment |
I guess the difficulty is that home directories are not publicly executable in your environment.
You can put an access control list on all home directories that gives a particular user or group execution permission to the directory. The web server will then potentially be able to access any file in users' home directories, which may provide ways to escalate privileges (at least, this will broaden the impact of a local file access vulnerability). For example, under Solaris or Linux, make sure the home filesystem is mounted with the acl option, and run
setfacl -m user:www-data:x /home/*
(integrate that into your account creation setup). Then tell your users that their ~/public_html directory must be readable by the www-data user; they can run this command:
setfacl -R -m default:user:www-data:rx ~/public_html
setfacl -R -m user:www-data:rx ~/public_html
Another possibility is to mount all the users' public_html directories in a separate place on the filesystem. This approach has the advantage that the permissions on the home directories won't matter; it even allows the web server to run chroooted. Under Linux, you can do this for a home directory:
mount --bind /home/joe/public_html /srv/homepages/joe
The public_html directory and its contents still need to be made accessible to www-data.
A variant on the Linux bind mount method uses the bindfs filesystem. This method works on any OS that supports bindfs (which is most unices) and does not require any ACL settings, at the cost that any file under public_html will be made available for reading by the web server.
bindfs -u www-data -p 500 /home/joe/public_html /srv/homepages/joe
I guess the difficulty is that home directories are not publicly executable in your environment.
You can put an access control list on all home directories that gives a particular user or group execution permission to the directory. The web server will then potentially be able to access any file in users' home directories, which may provide ways to escalate privileges (at least, this will broaden the impact of a local file access vulnerability). For example, under Solaris or Linux, make sure the home filesystem is mounted with the acl option, and run
setfacl -m user:www-data:x /home/*
(integrate that into your account creation setup). Then tell your users that their ~/public_html directory must be readable by the www-data user; they can run this command:
setfacl -R -m default:user:www-data:rx ~/public_html
setfacl -R -m user:www-data:rx ~/public_html
Another possibility is to mount all the users' public_html directories in a separate place on the filesystem. This approach has the advantage that the permissions on the home directories won't matter; it even allows the web server to run chroooted. Under Linux, you can do this for a home directory:
mount --bind /home/joe/public_html /srv/homepages/joe
The public_html directory and its contents still need to be made accessible to www-data.
A variant on the Linux bind mount method uses the bindfs filesystem. This method works on any OS that supports bindfs (which is most unices) and does not require any ACL settings, at the cost that any file under public_html will be made available for reading by the web server.
bindfs -u www-data -p 500 /home/joe/public_html /srv/homepages/joe
edited Feb 29 '12 at 1:20
answered Feb 29 '12 at 1:14
GillesGilles
530k12810631591
530k12810631591
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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%2funix.stackexchange.com%2fquestions%2f32950%2fallow-non-root-process-to-access-all-home-directories-without-compromising-secur%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