|
Home > Archive > Unix administration > January 2007 > Preventing file writes outside of a tree or filesystem
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Preventing file writes outside of a tree or filesystem
|
|
| Andre Majorel 2006-12-27, 7:29 am |
| Is there a way to run a subprocess so that it can read from all
files but not write to files outside of a tree or filesystem you
specify ? That would be on Linux but if there's a more general
solution, I'm interested in it.
--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
(Counterfeit: edev@freestone.com tyt@worst.com)
Religion: a magic device for turning unanswerable questions into
unquestionable answers. -- Art Gecko
| |
| Michael Vilain 2006-12-27, 7:29 am |
| In article <slrnep4ek1.2rv.cheney@atc5.vermine.org>,
Andre Majorel <cheney@halliburton.com> wrote:
> Is there a way to run a subprocess so that it can read from all
> files but not write to files outside of a tree or filesystem you
> specify ? That would be on Linux but if there's a more general
> solution, I'm interested in it.
The function you're looking for is called a chrooted directory try. A
restricted shell can use this. Look these ideas up in your man pages or
Linux books.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
| |
| Andre Majorel 2006-12-27, 7:29 am |
| On 2006-12-27, Michael Vilain <vilain@spamcop.net> wrote:
> In article <slrnep4ek1.2rv.cheney@atc5.vermine.org>,
> Andre Majorel <cheney@halliburton.com> wrote:
>
>
> The function you're looking for is called a chrooted directory
> try.
What is a "chrooted directory try" ?
> A restricted shell can use this.
chroot and restricted shells are useful but not an answer to the
question above.
--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
(Counterfeit: nabewyz@concurrent.com codimaw@predicament.com)
Religion: a magic device for turning unanswerable questions into
unquestionable answers. -- Art Gecko
| |
| Dave Hinz 2006-12-27, 7:29 am |
| On Wed, 27 Dec 2006 10:09:43 +0000 (UTC), Andre Majorel <cheney@halliburton.com> wrote:
> On 2006-12-27, Michael Vilain <vilain@spamcop.net> wrote:
>
> What is a "chrooted directory try" ?
>
>
> chroot and restricted shells are useful but not an answer to the
> question above.
Perhaps instead of lecturing someone who gave you a perfectly correct
answer, you could tell us how you feel this doesn't meet your needs.
Why, for instance, would someone have write permission where they
shouldn't, for starters? What is it you're actually trying to
accomplish?
| |
| Todd H. 2006-12-27, 1:16 pm |
| Andre Majorel <cheney@halliburton.com> writes:
> Is there a way to run a subprocess so that it can read from all
> files but not write to files outside of a tree or filesystem you
> specify ? That would be on Linux but if there's a more general
> solution, I'm interested in it.
Dunno what you're trying to accomplish but I'll offer that forensic
analysis setups interface to the hard disk being analyzed using a
cable that physically has the write wires disconnected to the hard
drive. That's the only way you're really sure no writes are taking
place to that volume.
No writing to a filesystem is relatively easy in unix... just mount
the partition read only. The man page for mount will tell you about
-r option or -o ro.
For a given subdirectory of a mounted volume, I'm not aware of an
existing solution.
--
Todd H.
http://www.toddh.net/
| |
| Stefaan A Eeckels 2006-12-27, 1:16 pm |
| On Wed, 27 Dec 2006 09:18:58 +0000 (UTC)
Andre Majorel <cheney@halliburton.com> wrote:
> Is there a way to run a subprocess so that it can read from all
> files but not write to files outside of a tree or filesystem you
> specify ? That would be on Linux but if there's a more general
> solution, I'm interested in it.
>
Access privileges are granted to users and not to processes, so you
cannot ask the OS to restrict file access to a specific process. A
fairly hackish approach would be to preload a library that intercepts
the "open" call and applies your access policies.
I suspect you're asking the wrong question. What exactly are you trying
to achieve?
--
Stefaan A Eeckels
--
....one of the chief advantages of a CLI over a GUI: people who are
truly clueless are more likely to give up and walk away before they
mess things up too badly. --Logan Shaw
| |
| Andre Majorel 2006-12-27, 1:16 pm |
| On 2006-12-27, Stefaan A Eeckels <hoendech@ecc.lu> wrote:
> On Wed, 27 Dec 2006 09:18:58 +0000 (UTC)
> Andre Majorel <cheney@halliburton.com> wrote:
>
>
> Access privileges are granted to users and not to processes,
> so you cannot ask the OS to restrict file access to a specific
> process.
ulimit can certainly prevent a process from writing to files.
> A fairly hackish approach would be to preload a library that
> intercepts the "open" call and applies your access policies.
Yes. A mechanism to prevent open(O_RDWR/O_WRONLY) to fail if the
pathname is not kosher would be good enough for me.
> I suspect you're asking the wrong question. What exactly are
> you trying to achieve?
Is there is a way to prevent a process from consuming any disk
space outside of a chosen directory or filesystem ? The process
does not cooperate (suppose no access to the source code) but is
not actively hostile either. I'm not trying to guard against
attacks, only bugs and operator errors.
chroot is too much work to set up and maintain. Playing with
permissions won't work for several reasons, one of them being
that some of the processes need to run as root. Running the
process inside a virtual machine and preloading open(2) are of
course possibilities but the point is, if there's a standard
facility for that (E.G. something like ulimit), I'd like to
learn about it.
--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
(Counterfeit: ufuzac@dissertation.com niruw@companion.com)
Religion: a magic device for turning unanswerable questions into
unquestionable answers. -- Art Gecko
| |
| Michael Vilain 2006-12-27, 1:16 pm |
| In article <slrnep5bbi.2rv.cheney@atc5.vermine.org>,
Andre Majorel <cheney@halliburton.com> wrote:
> On 2006-12-27, Stefaan A Eeckels <hoendech@ecc.lu> wrote:
>
> ulimit can certainly prevent a process from writing to files.
>
>
> Yes. A mechanism to prevent open(O_RDWR/O_WRONLY) to fail if the
> pathname is not kosher would be good enough for me.
>
>
> Is there is a way to prevent a process from consuming any disk
> space outside of a chosen directory or filesystem ? The process
> does not cooperate (suppose no access to the source code) but is
> not actively hostile either. I'm not trying to guard against
> attacks, only bugs and operator errors.
>
> chroot is too much work to set up and maintain. Playing with
> permissions won't work for several reasons, one of them being
> that some of the processes need to run as root. Running the
> process inside a virtual machine and preloading open(2) are of
> course possibilities but the point is, if there's a standard
> facility for that (E.G. something like ulimit), I'd like to
> learn about it.
if chroot doesn't work for you "because it's to much work", I suggest
you look at the sources for your OS and put changes in the open() call
to implement the limits you're looking for. AFAIK, most UNIX system
can' do this (unless there's some NSA-variant which if I told you about
I'd have to kill you).
--
DeeDee, don't press that button! DeeDee! NO! Dee...
| |
| Todd H. 2006-12-27, 1:16 pm |
| Andre Majorel <cheney@halliburton.com> writes:
> On 2006-12-27, Stefaan A Eeckels <hoendech@ecc.lu> wrote:
>
> ulimit can certainly prevent a process from writing to files.
>
>
> Yes. A mechanism to prevent open(O_RDWR/O_WRONLY) to fail if the
> pathname is not kosher would be good enough for me.
>
>
> Is there is a way to prevent a process from consuming any disk
> space outside of a chosen directory or filesystem ?
No.
Now will you please go away?
--
Todd H.
http://www.toddh.net/
| |
|
|
Todd H. wrote:
> Andre Majorel <cheney@halliburton.com> writes:
>
>
> No.
It's been quite a while since I've worked with quotas, but ISTR at
least one OS (PR1MOS) allowed setting quotas at the directory level.
This was handy in certain environments, such as controlling runaway
Comp Sci. 101 programs ;)
Looking at AIX and Linux in front of me, it appears 'quota' to only
apply at the filesystem level.
I suppose you could create a special user-id that you only ever use for
running this process, to get around the constraint that you can't
control it at the PID level. Then get cute with the command (e.g. limit
that user to nothing)?
Never tried it though, YMMV, proceed at your own risk ;)
Regards,
Jon
| |
| Stefaan A Eeckels 2006-12-27, 7:22 pm |
| On Wed, 27 Dec 2006 17:29:27 +0000 (UTC)
Andre Majorel <cheney@halliburton.com> wrote:
> On 2006-12-27, Stefaan A Eeckels <hoendech@ecc.lu> wrote:
>
> ulimit can certainly prevent a process from writing to files.
Yes, but not based on their place in the file hierarchy.
>
> Yes. A mechanism to prevent open(O_RDWR/O_WRONLY) to fail if the
> pathname is not kosher would be good enough for me.
Well, then implement a library with the required function, and
LD_PRELOAD it when the process in question is spawned. You'll probably
also want to do something about "stat" so that the process doesn't get
confused when it fails to open a file that is reported to have write
access. I wouldn't be amazed if it turned out to be a fairly complex
thing to get right.
>
>
> Is there is a way to prevent a process from consuming any disk
> space outside of a chosen directory or filesystem ? The process
> does not cooperate (suppose no access to the source code) but is
> not actively hostile either. I'm not trying to guard against
> attacks, only bugs and operator errors.
If you're willing to set up quotas for the various file systems you can
stop the process from using too much disk space, but you cannot stop it
from opening files for writing. In addition, many programs don't know
how to deal with out-of-disk-space errors, so the cure might be worse
than the disease.
> chroot is too much work to set up and maintain. Playing with
> permissions won't work for several reasons, one of them being
> that some of the processes need to run as root. Running the
> process inside a virtual machine and preloading open(2) are of
> course possibilities but the point is, if there's a standard
> facility for that (E.G. something like ulimit), I'd like to
> learn about it.
There is no standard way of doing what you want to do.
You're probably solving the wrong problem anyway - if a program wreaks
havoc in file systems or directories where it has no business, then it
should be fixed, and certainly never be run as root. If you have no
access to the source code, and it is buggy to the point that you need
to protect your system from its undesirable side-effects, it's time to
seriously consider why you're using it.
If you really _have_ to use it, then the best solution is to set up a
VM for the purpose of running the critter. Not expensive at all now
that VMWare Server is free of charge.
Take care,
--
Stefaan A Eeckels
--
Rules of the Evil European Overlord #191. "I will not appoint a relative
to my staff of advisors. Not only is nepotism the cause of most
breakdowns in policy, but it also causes trouble with OLAF."
with thanks to <http://www.eviloverlord.com/>
| |
| Dave Hinz 2006-12-27, 7:22 pm |
| On Wed, 27 Dec 2006 17:29:27 +0000 (UTC), Andre Majorel <cheney@halliburton.com> wrote:
> Is there is a way to prevent a process from consuming any disk
> space outside of a chosen directory or filesystem ? The process
> does not cooperate (suppose no access to the source code) but is
> not actively hostile either. I'm not trying to guard against
> attacks, only bugs and operator errors.
Sounds like a disk quota question?
> chroot is too much work to set up and maintain. Playing with
> permissions won't work for several reasons, one of them being
> that some of the processes need to run as root.
RUN AWAY.
| |
| Barry Margolin 2006-12-28, 1:34 am |
| In article <4vf7n0F1bg10vU1@mid.individual.net>,
Dave Hinz <DaveHinz@gmail.com> wrote:
> On Wed, 27 Dec 2006 10:09:43 +0000 (UTC), Andre Majorel
> <cheney@halliburton.com> wrote:
>
>
> Perhaps instead of lecturing someone who gave you a perfectly correct
> answer, you could tell us how you feel this doesn't meet your needs.
> Why, for instance, would someone have write permission where they
> shouldn't, for starters? What is it you're actually trying to
> accomplish?
He said that only writes should be restricted to the filesystem, while
reads should be unrestricted. chroot would limit both.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Barry Margolin 2006-12-28, 1:34 am |
| In article <4vghh3F1bm3h9U3@mid.individual.net>,
Dave Hinz <DaveHinz@gmail.com> wrote:
> On Wed, 27 Dec 2006 17:29:27 +0000 (UTC), Andre Majorel
> <cheney@halliburton.com> wrote:
>
>
> Sounds like a disk quota question?
>
>
> RUN AWAY.
This also makes quotas unlikely to work. Quota is per-user, not
per-process.
Are quotas enforced against root?
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Dave Hinz 2006-12-28, 1:34 am |
| On Wed, 27 Dec 2006 23:20:18 -0500, Barry Margolin <barmar@alum.mit.edu> wrote:
> In article <4vghh3F1bm3h9U3@mid.individual.net>,
> Dave Hinz <DaveHinz@gmail.com> wrote:
>
>
> This also makes quotas unlikely to work. Quota is per-user, not
> per-process.
Yup.
> Are quotas enforced against root?
Dunno, haven't needed to know in a decade or so. Sounds like the lad
needs to tell the app owner to get the app to behave properly. If it
has to run as root, well, that severly limits the options and leaves the
potential for damage wide open.
>
| |
| Andre Majorel 2007-01-06, 8:01 pm |
| On 2006-12-27, Stefaan A Eeckels <hoendech@ecc.lu> wrote:
> On Wed, 27 Dec 2006 17:29:27 +0000 (UTC)
> Andre Majorel <cheney@halliburton.com> wrote:
>
>
> Well, then implement a library with the required function, and
> LD_PRELOAD it when the process in question is spawned. You'll probably
> also want to do something about "stat" so that the process doesn't get
> confused when it fails to open a file that is reported to have write
> access.
Oh but I don't care if it does. All I ask is that it does not
take the system down in the process.
>
> If you're willing to set up quotas for the various file systems you can
> stop the process from using too much disk space, but you cannot stop it
> from opening files for writing.
Hadn't thought of quotas. Thank you. I'll look into it.
> You're probably solving the wrong problem anyway - if a program wreaks
> havoc in file systems or directories where it has no business, then it
> should be fixed, and certainly never be run as root.
Likewise, security belts should be removed because drivers are
supposed to know how to stay on the road.
--
André Majorel <URL:http://www.teaser.fr/~amajorel/>
(Counterfeit: tujof@further.com opyv@knott.com)
Religion: a magic device for turning unanswerable questions into
unquestionable answers. -- Art Gecko
| |
| Stefaan A Eeckels 2007-01-06, 8:01 pm |
| On Thu, 28 Dec 2006 21:34:54 +0000 (UTC)
Andre Majorel <cheney@halliburton.com> wrote:
>
> Likewise, security belts should be removed because drivers are
> supposed to know how to stay on the road.
I don't think that's an accurate comparison. You want to design a system
to protect drivers from being randomly shot by the police.
If you have to run a program as root you should be quite certain of its
behaviour, because the system isn't designed to protect itself against
the root user. That's a fundamental of Unix systems, and unless you
have something like Solaris RBAC (Role-Based Access Control), you
should restrict the use of root to a strict minimum. Applications
should never have to run as root, or should be sufficiently trusted.
If you are saddled with this program, you really should download a copy
of VMWare Server for Linux, and run the thing in a sandbox.
If it's supposed to be a system management or system monitoring
program that needs access to the whole system, get rid of it. Anything
else would be irresponsible.
--
Stefaan A Eeckels
--
Microsoft treats IT managers the way Proctor & Gamble treats
nine-year-old prospective consumers: lots of noise, bright colors, and
jumping around. Other software vendors just wish they could be so
successful. -- Cameron Laird in comp.lang.tcl
| |
| Michael Paoli 2007-01-08, 7:23 am |
| Andre Majorel wrote:
[vbcol=seagreen]
> chroot is too much work to set up and maintain. Playing with
> permissions won't work for several reasons, one of them being
> that some of the processes need to run as root. Running the
Generally speaking, root can bypass any restrictions on the operating
system short of secure encryption, so there may be no direct complete
solution.
Perhaps if you run the operating system from a CD-ROM or DVD, and use
a RAM based filesystem for the one filesystem you want the subprocess
to be able to write to.
On UNIX, permissions will generally prevent non-privileged processes
from writing where they shouldn't write. In general, root can write
anywhere it is possible to write.
|
|
|
|
|