/proc/sys/fs/protected_regular (since Linux 4.19)
1 Don't allow O_CREAT open(2) on regular files that the caller doesn't
own in world-writable sticky directories, unless the regular file is
owned by the owner of the directory.
2 As for the value 1, but the restriction also applies to
group-writable sticky directories.
The intent of the above protections is similar to protected_fifos, but
allows an application to avoid writes to an attacker-controlled regular
file, where the application expected to create one.
On 2024-05-23, Rainer Weikusat <[email protected]> wrote:
/proc/sys/fs/protected_regular (since Linux 4.19)
1 Don't allow O_CREAT open(2) on regular files that the caller doesn't
own in world-writable sticky directories, unless the regular file is
owned by the owner of the directory.
That makes no sense. In the absence of O_EXCL, O_CREAT pertains to files
that don't exist. Files that don't exist do not have an owner.
If the file exists, and O_CREAT is specified, but not O_EXCL, then
O_CREAT means nothing.
2 As for the value 1, but the restriction also applies to
group-writable sticky directories.
The intent of the above protections is similar to protected_fifos, but
allows an application to avoid writes to an attacker-controlled regular
file, where the application expected to create one.
If a file is attacker-controlled, that is independent of the
circumstances of its creation.
We can think about a protection mechanism that, in certain directories, prevents a process from obtaining an open file descriptor to an attacker-controlled file, regardless of whether it is being created.
Kaz Kylheku <[email protected]> writes:
We can think about a protection mechanism that, in certain directories,
prevents a process from obtaining an open file descriptor to an
attacker-controlled file, regardless of whether it is being created.
This leads to another question: What on G*ds f***ing earth is "an
attacker controlled regular file" security-wise? It's not that regular
files do anything. They just store data. I can think of seriously
contrived issue here, namely, broken app tries to create a file with >restrictive permissions in order to write $super_secret_stuff to it and >accidentally writes it to a file readable by another user instead. If
that's a real issue, I haven't heard of it yet. And I certainly don't
think this justifies breaking working, correct code which makes use of
UNIX semantics some Google employee happens to dislike.
This leads to another question: What on G*ds f***ing earth is "an
attacker controlled regular file" security-wise? It's not that regular
files do anything. They just store data. I can think of seriously
contrived issue here, namely, broken app tries to create a file with restrictive permissions in order to write $super_secret_stuff to it and accidentally writes it to a file readable by another user instead. If
that's a real issue, I haven't heard of it yet.
Rainer Weikusat <[email protected]> writes:
This leads to another question: What on G*ds f***ing earth is "an
attacker controlled regular file" security-wise? It's not that regular
files do anything. They just store data. I can think of seriously
contrived issue here, namely, broken app tries to create a file with
restrictive permissions in order to write $super_secret_stuff to it and
accidentally writes it to a file readable by another user instead. If
that's a real issue, I haven't heard of it yet.
The typical example is an install script which downloads the main
installer to a predictable filename in /tmp and then executes it.
Broken, indeed, but nevertheless a recurring issue.
The attacker pre-creates the download file with 0777 permission and then injects their own code into it; it will subsequently be run as the
victim user.
There’s a race to win here, i.e. getting a modification in
before execution completes, but it seems to be easy in practice.
People presumably set protected_regular=0 if the attack scenario never
arises in their environment, or if they prefer to take the risk.
Rainer Weikusat <[email protected]> writes:
This leads to another question: What on G*ds f***ing earth is "an
attacker controlled regular file" security-wise? It's not that regular
files do anything. They just store data. I can think of seriously
contrived issue here, namely, broken app tries to create a file with
restrictive permissions in order to write $super_secret_stuff to it and
accidentally writes it to a file readable by another user instead. If
that's a real issue, I haven't heard of it yet.
The typical example is an install script which downloads the main
installer to a predictable filename in /tmp and then executes it.
Broken, indeed, but nevertheless a recurring issue.
The attacker pre-creates the download file with 0777 permission and then injects their own code into it; it will subsequently be run as the
victim user.
There’s a race to win here, i.e. getting a modification in
before execution completes, but it seems to be easy in practice.
People presumably set protected_regular=0 if the attack scenario never
arises in their environment, or if they prefer to take the risk.
Richard Kettlewell <[email protected]d> writes:
Rainer Weikusat <[email protected]> writes:
This leads to another question: What on G*ds f***ing earth is "an
attacker controlled regular file" security-wise? It's not that regular
files do anything. They just store data. I can think of seriously
contrived issue here, namely, broken app tries to create a file with
restrictive permissions in order to write $super_secret_stuff to it and
accidentally writes it to a file readable by another user instead. If
that's a real issue, I haven't heard of it yet.
The typical example is an install script which downloads the main
installer to a predictable filename in /tmp and then executes it.
Broken, indeed, but nevertheless a recurring issue.
That's not really broken, only stupid. The broken bit is not using
O_EXCL to create the file. And the broken bit of the chokearound is
changing well-documented semantics of open flags with real uses cases
based on the assumption that O_EXCL must have been 'forgotten'.
The attacker pre-creates the download file with 0777 permission and
then injects their own code into it; it will subsequently be run as
the victim user.
There’s a race to win here, i.e. getting a modification in before
execution completes, but it seems to be easy in practice.
There's another 'race' to win here, namely, it must somehow be known
that a broken install script is about to be executed in order to
'attack' anyone.
Rainer Weikusat <[email protected]> writes:
Richard Kettlewell <[email protected]d> writes:
Rainer Weikusat <[email protected]> writes:
This leads to another question: What on G*ds f***ing earth is "an
attacker controlled regular file" security-wise? It's not that regular >>>> files do anything. They just store data. I can think of seriously
contrived issue here, namely, broken app tries to create a file with
restrictive permissions in order to write $super_secret_stuff to it and >>>> accidentally writes it to a file readable by another user instead. If
that's a real issue, I haven't heard of it yet.
The typical example is an install script which downloads the main
installer to a predictable filename in /tmp and then executes it.
Broken, indeed, but nevertheless a recurring issue.
That's not really broken, only stupid. The broken bit is not using
O_EXCL to create the file. And the broken bit of the chokearound is
changing well-documented semantics of open flags with real uses cases
based on the assumption that O_EXCL must have been 'forgotten'.
The adjective used to describe it isn’t the point. The point is that it keeps happening.
The attacker pre-creates the download file with 0777 permission and
then injects their own code into it; it will subsequently be run as
the victim user.
There’s a race to win here, i.e. getting a modification in before
execution completes, but it seems to be easy in practice.
There's another 'race' to win here, namely, it must somehow be known
that a broken install script is about to be executed in order to
'attack' anyone.
Easy enough to arrange in a shared environment. Find a bit of software relevant to the attacker’s job (or the job of whoever’s unprivileged login they’ve compromised) and ask the IT department to install it.
On Mon, 27 May 2024 09:19:30 +0100
Richard Kettlewell <[email protected]d> wrote:
Easy enough to arrange in a shared environment. Find a bit of software
relevant to the attacker’s job (or the job of whoever’s unprivileged
login they’ve compromised) and ask the IT department to install it.
That's a social-engineering problem, not a software-engineering one.
Trying to solve "people in positions of responsibility aren't being responsible" by technical means has never worked and *will* never work.
On Tue, 28 May 2024 07:57:07 -0700
John Ames <[email protected]> wrote:
That's a social-engineering problem, not a software-engineering one.
Trying to solve "people in positions of responsibility aren't being
responsible" by technical means has never worked and *will* never
work.
(On top of which, if the concern really boils down to "filename
collisions in /tmp are exploitable,"
John Ames <[email protected]> writes:
On Tue, 28 May 2024 07:57:07 -0700
John Ames <[email protected]> wrote:
That's a social-engineering problem, not a software-engineering one.
Trying to solve "people in positions of responsibility aren't being
responsible" by technical means has never worked and *will* never
work.
(On top of which, if the concern really boils down to "filename
collisions in /tmp are exploitable,"
It's more like "Programs which wrongly assume they have exclusive
control over the filesystem name space, ie, which - due to lazinness or >incompetence of their resepective authors - fail to use the abundantly >availabe mechanisms for ensuring they exclusivley control 'their' names,
can be exploited."
Richard Kettlewell <[email protected]d> wrote:
Easy enough to arrange in a shared environment. Find a bit of software
relevant to the attacker’s job (or the job of whoever’s unprivileged
login they’ve compromised) and ask the IT department to install it.
That's a social-engineering problem, not a software-engineering one.
Trying to solve "people in positions of responsibility aren't being responsible" by technical means has never worked and *will* never work.
[email protected], dans le message <v36kd8$11r1b$[email protected]>,
a �crit�:
The simple answer being that no process uses /tmp unless it needs to share >> data with another via files.
So where should they put their temporary files?
The simple answer being that no process uses /tmp unless it needs to share data with another via files.
John Ames <[email protected]> writes:
Richard Kettlewell <[email protected]d> wrote:
Easy enough to arrange in a shared environment. Find a bit of software
relevant to the attacker’s job (or the job of whoever’s unprivileged >>> login they’ve compromised) and ask the IT department to install it.
That's a social-engineering problem, not a software-engineering one.
Trying to solve "people in positions of responsibility aren't being
responsible" by technical means has never worked and *will* never work.
It’s easy to think of counterexamples: collision assist in a car, for instance, or automatic braking systems in trains.
Nicolas George <nicolas$[email protected]> writes:
[email protected], dans le message <v36kd8$11r1b$[email protected]>,
a écrit :
The simple answer being that no process uses /tmp unless it needs to share >>> data with another via files.
So where should they put their temporary files?
$ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
Note that /tmp and /var/tmp usually have the "Sticky" mode bit
set which limits the operations that a non-owner can
perform on a file in that directory.
Richard Kettlewell <[email protected]d> wrote:
John Ames <[email protected]> writes:
That's a social-engineering problem, not a software-engineering one.
Trying to solve "people in positions of responsibility aren't being
responsible" by technical means has never worked and *will* never
work.
It’s easy to think of counterexamples: collision assist in a car, for
instance, or automatic braking systems in trains.
Minimal-assistance-in-the-absence-of-direct-supervision is a *very*
different thing from intelligent-override-of-deliberate-action.
[email protected], dans le message <v36kd8$11r1b$[email protected]>,
a �crit�:
The simple answer being that no process uses /tmp unless it needs to share >> data with another via files.
So where should they put their temporary files?
On Wed, 29 May 2024 18:12:20 +0100
Rainer Weikusat <[email protected]> wrote:
[email protected] (Scott Lurndal) writes:
Nicolas George <nicolas$[email protected]> writes: >>>>[email protected], dans le message <v36kd8$11r1b$[email protected]>, >>>> a écrit :
The simple answer being that no process uses /tmp unless it needs to share
data with another via files.
So where should they put their temporary files?
$ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
Note that /tmp and /var/tmp usually have the "Sticky" mode bit
set which limits the operations that a non-owner can
perform on a file in that directory.
This solves only half of the problem: mkdir will fail if the given >>filesystem name already exists. Some scheme to create unguessable names
and try using them until success would still be needed on top of that.
Process id + time and date down to the microsecond in the filename usually >solves that problem. If multi threaded then throw in the thread id too. >Creating unique filenames isn't a problem so long as everyone sticks to the >scheme.
[email protected] (Scott Lurndal) writes:
Nicolas George <nicolas$[email protected]> writes: >>>[email protected], dans le message <v36kd8$11r1b$[email protected]>,
a écrit :
The simple answer being that no process uses /tmp unless it needs to share >>>> data with another via files.
So where should they put their temporary files?
$ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
Note that /tmp and /var/tmp usually have the "Sticky" mode bit
set which limits the operations that a non-owner can
perform on a file in that directory.
This solves only half of the problem: mkdir will fail if the given
filesystem name already exists. Some scheme to create unguessable names
and try using them until success would still be needed on top of that.
[email protected] writes:
On Wed, 29 May 2024 18:12:20 +0100
Rainer Weikusat <[email protected]> wrote:
[email protected] (Scott Lurndal) writes:
Nicolas George <nicolas$[email protected]> writes: >>>>>[email protected], dans le message <v36kd8$11r1b$[email protected]>, >>>>> a écrit :
The simple answer being that no process uses /tmp unless it needs to >share
data with another via files.
So where should they put their temporary files?
$ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
Note that /tmp and /var/tmp usually have the "Sticky" mode bit
set which limits the operations that a non-owner can
perform on a file in that directory.
This solves only half of the problem: mkdir will fail if the given >>>filesystem name already exists. Some scheme to create unguessable names >>>and try using them until success would still be needed on top of that.
Process id + time and date down to the microsecond in the filename usually >>solves that problem. If multi threaded then throw in the thread id too. >>Creating unique filenames isn't a problem so long as everyone sticks to the >>scheme.
$ man 1 mktemp
Nicolas George <nicolas$[email protected]> writes:
[email protected], dans le message <v36kd8$11r1b$[email protected]>,
a écrit :
The simple answer being that no process uses /tmp unless it needs to
share
data with another via files.
So where should they put their temporary files?
$ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
Rainer Weikusat <[email protected]> wrote:
[email protected] (Scott Lurndal) writes:
Nicolas George <nicolas$[email protected]> writes: >>>>[email protected], dans le message <v36kd8$11r1b$[email protected]>, >>>> a écrit :
The simple answer being that no process uses /tmp unless it needs to share
data with another via files.
So where should they put their temporary files?
$ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
Note that /tmp and /var/tmp usually have the "Sticky" mode bit
set which limits the operations that a non-owner can
perform on a file in that directory.
This solves only half of the problem: mkdir will fail if the given >>filesystem name already exists. Some scheme to create unguessable names
and try using them until success would still be needed on top of that.
Process id + time and date down to the microsecond in the filename usually solves that problem. If multi threaded then throw in the thread id too. Creating unique filenames isn't a problem so long as everyone sticks to the scheme.
Create a dot directory in the users home dir
[email protected], dans le message <v37no9$17tpi$[email protected]>,
a �crit�:
Create a dot directory in the users home dir
So you suggest to use for temporary files a place where space might be >limited, and/or slow, and/or with expensive writes?
That's rather bad design.
On 29 May 2024 21:48:57 GMT
Nicolas George <nicolas$[email protected]> wrote:
[email protected], dans le message <v37no9$17tpi$[email protected]>,
a �crit�:
Create a dot directory in the users home dir
So you suggest to use for temporary files a place where space might be >>limited, and/or slow, and/or with expensive writes?
That's rather bad design.
You conveniently snipped the bit where I mentioned quotas. However you might >want to take a look in your home directory at all the . files (and some not) >and look at what various desktop apps dump there. Eg Various browsers save >megabytes of cache data.
[email protected] writes:
Rainer Weikusat <[email protected]> wrote:
[email protected] (Scott Lurndal) writes:
Nicolas George <nicolas$[email protected]> writes: >>>>>[email protected], dans le message <v36kd8$11r1b$[email protected]>, >>>>> a écrit :
The simple answer being that no process uses /tmp unless it needs to >share
data with another via files.
So where should they put their temporary files?
$ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
Note that /tmp and /var/tmp usually have the "Sticky" mode bit
set which limits the operations that a non-owner can
perform on a file in that directory.
This solves only half of the problem: mkdir will fail if the given >>>filesystem name already exists. Some scheme to create unguessable names >>>and try using them until success would still be needed on top of that.
Process id + time and date down to the microsecond in the filename usually >> solves that problem. If multi threaded then throw in the thread id too.
Creating unique filenames isn't a problem so long as everyone sticks to the >> scheme.
BASE64-encoding a random number would also work. But I didn't claim this >would be particularly complicated, just that it needed to be done.
You conveniently snipped the bit where I mentioned quotas.
[email protected], dans le message <v3bu5o$24p7r$[email protected]>,
a �crit�:
You conveniently snipped the bit where I mentioned quotas.
Indeed: it did not make your suggestion better.
My suggestion is how a lot of modern applications work
[email protected] writes:
Rainer Weikusat <[email protected]> wrote:
[email protected] writes:
Rainer Weikusat <[email protected]> wrote:
[email protected] (Scott Lurndal) writes:Process id + time and date down to the microsecond in the filename usually
Nicolas George <nicolas$[email protected]> writes: >>>>>>>[email protected], dans le message <v36kd8$11r1b$[email protected]>, >>>>>>> a écrit :
The simple answer being that no process uses /tmp unless it needs to >>>share
data with another via files.
So where should they put their temporary files?
$ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
Note that /tmp and /var/tmp usually have the "Sticky" mode bit
set which limits the operations that a non-owner can
perform on a file in that directory.
This solves only half of the problem: mkdir will fail if the given >>>>>filesystem name already exists. Some scheme to create unguessable names >>>>>and try using them until success would still be needed on top of that. >>>>
solves that problem. If multi threaded then throw in the thread id too. >>>> Creating unique filenames isn't a problem so long as everyone sticks to the
scheme.
BASE64-encoding a random number would also work. But I didn't claim this >>>would be particularly complicated, just that it needed to be done.
Always the danger of a collision if both programs seeded the sequence with >> the same value, albeit very small.
Regardless of the scheme that's employed, there's always a danger of >collisions, ie, of some other processing having created a file with this
name first.
Rainer Weikusat <[email protected]> wrote:
[email protected] writes:
Rainer Weikusat <[email protected]> wrote:
[email protected] (Scott Lurndal) writes:
Nicolas George <nicolas$[email protected]> writes: >>>>>>[email protected], dans le message <v36kd8$11r1b$[email protected]>, >>>>>> a écrit :
The simple answer being that no process uses /tmp unless it needs to >>share
data with another via files.
So where should they put their temporary files?
$ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
Note that /tmp and /var/tmp usually have the "Sticky" mode bit
set which limits the operations that a non-owner can
perform on a file in that directory.
This solves only half of the problem: mkdir will fail if the given >>>>filesystem name already exists. Some scheme to create unguessable names >>>>and try using them until success would still be needed on top of that.
Process id + time and date down to the microsecond in the filename usually >>> solves that problem. If multi threaded then throw in the thread id too.
Creating unique filenames isn't a problem so long as everyone sticks to the >>> scheme.
BASE64-encoding a random number would also work. But I didn't claim this >>would be particularly complicated, just that it needed to be done.
Always the danger of a collision if both programs seeded the sequence with the same value, albeit very small.
On Fri, 31 May 2024 15:23:35 +0100
Rainer Weikusat <[email protected]> wrote:
[email protected] writes:
Rainer Weikusat <[email protected]> wrote:
[email protected] writes:
Rainer Weikusat <[email protected]> wrote:
[email protected] (Scott Lurndal) writes:Process id + time and date down to the microsecond in the filename usually
Nicolas George <nicolas$[email protected]> writes: >>>>>>>>[email protected], dans le message <v36kd8$11r1b$[email protected]>,
a écrit :
The simple answer being that no process uses /tmp unless it needs to >>>>share
data with another via files.
So where should they put their temporary files?
$ mkdir ${TMPDIR}/${LOGNAME} && chown 1700 ${TMPDIR}/${LOGNAME}
Note that /tmp and /var/tmp usually have the "Sticky" mode bit
set which limits the operations that a non-owner can
perform on a file in that directory.
This solves only half of the problem: mkdir will fail if the given >>>>>>filesystem name already exists. Some scheme to create unguessable names >>>>>>and try using them until success would still be needed on top of that. >>>>>
solves that problem. If multi threaded then throw in the thread id too. >>>>> Creating unique filenames isn't a problem so long as everyone sticks to the
scheme.
BASE64-encoding a random number would also work. But I didn't claim this >>>>would be particularly complicated, just that it needed to be done.
Always the danger of a collision if both programs seeded the sequence with >>> the same value, albeit very small.
Regardless of the scheme that's employed, there's always a danger of >>collisions, ie, of some other processing having created a file with this >>name first.
After a program has exited it has no claim to any temporary files so thats
a non issue.
[email protected] writes:
After a program has exited it has no claim to any temporary files so thats >> a non issue.
It's an issue because a program may intentionally create files (or
symlinks) with names another program will likely try to use for a
temporary file in the near future. The same may happen for less
nefarious reasons because "shit happened", which it's wont to do.
In the general case, programs creating files in world-writable
directories need to handle the situation that another program might try
to use the same filename at the same time.
Richard Kettlewell <[email protected]d> wrote:
John Ames <[email protected]> writes:
Minimal-assistance-in-the-absence-of-direct-supervision is a *very*
different thing from intelligent-override-of-deliberate-action.
I think some automated braking for goalposts is needed here.
Let me come back at my point, then: security precautions predicated on
the assumption that an Authorized Person is not operating in good faith
and due diligence concordant with their level of authorization suffer
from severe diminishing returns with each additional layer of safeguard
and may even reach a point where they're *counterproductive.*
Restricting the ability to install software to a designated group of administrators, f'rexample, is a perfectly sensible thing to do,
especially in a large shared system.
But once you've created such a group, assessing whether a given
individual is trustworthy and knowledgeable enough to be a member of
it is an organizational problem, *not* a technical one.
Some measure of safeguarding may still be worth the bother despite this (while Windows's "hey, you got this thing off the Interwebs, you sure 'sokay?" prompts annoy me personally, I can see the logic behind them,)
but every additional layer calls further into question what the point
of even having the group is in the first place, and whether *anyone*
should really be a member of it. If not, why did you let them in? If
so, why are you hampering their ability to exercise that authority?
This has become semi-famously an issue in medical software, for
instance. Developers of some major EMR systems, driven by regulatory
and legal CYA concerns, have put so many are-you-sure and please- acknowledge-XYZ prompts into their core workflow that doctors (who are, shockingly, only human) end up clicking through them machine-gun style,
and pay *less* attention to the actually critical stuff than they
would've if it weren't buried in an avalanche of white noise.
And doctors aren't software specialists; sysadmins *are.* Throw too
many safeguards in the path of a sysadmin just trying to get shit done,
and you don't end up with a sysadmin forced to question whether they
really *are* sure, or even a sysadmin powering doctor-style through a
set of nagging little obstacles they aren't thinking about; you end up
with a sysadmin who will - guaranteed - develop a process of *disabling
the entire safeguard system* for the duration of the job, and then (if
you're lucky) re-enabling it afterward.
We saw exactly that with UAC in Windows Vista; it was so bad that the #1 method for dealing with it was to disable it entirely, and people were
so burned by it that that remained true *well* into the Win10 era,
despite MS's attempts to temper it into some measure of reasonability.
So no, I don't think that a couple examples of minimal assistance in situations where direct supervision is either absent or impaired *do* constitute a hard-and-fast argument against temperance in security
design as a general principle. Sometimes a little extra safety is worth
it, sometimes not; and sometimes you're actually shooting yourself in
the foot.
I think collision assist is really good model for protected_regular.
The potential collision might be due to the driver’s occasional
inattention (analogy: sysadmin writes scripts most days, but mis-handles filename spoofing risks occasionally) or it might be someone else’s
error (analogy: insecure download+install script).
The collision assist doesn’t prevent normal driving, it only activates
when things are about to go seriously wrong[2]; for almost everybody the
same is true of protected_regular, it only blocks anything when an
attack is underway.
Richard Kettlewell <[email protected]d> writes:
I think collision assist is really good model for protected_regular.
The potential collision might be due to the driver’s occasional
inattention (analogy: sysadmin writes scripts most days, but mis-handles
filename spoofing risks occasionally) or it might be someone else’s
error (analogy: insecure download+install script).
The collision assist doesn’t prevent normal driving, it only activates
when things are about to go seriously wrong[2]; for almost everybody the
same is true of protected_regular, it only blocks anything when an
attack is underway.
protected_regular does prevent "normal driving" and it decidedly
'activates' in situations where nothing untoward is underway. I've
described an example of that.
On Fri, 31 May 2024 22:18:16 +0100
Rainer Weikusat <[email protected]> wrote:
[email protected] writes:
In the general case, programs creating files in world-writable
directories need to handle the situation that another program might try
to use the same filename at the same time.
Which is why you give your file a unique name. However there is no 100% fullproof solution to this issue so if you're worried about it don't write
to a world writable directory.
Rainer Weikusat <[email protected]> writes:
Richard Kettlewell <[email protected]d> writes:
I think collision assist is really good model for protected_regular.
The potential collision might be due to the driver’s occasional
inattention (analogy: sysadmin writes scripts most days, but mis-handles >>> filename spoofing risks occasionally) or it might be someone else’s
error (analogy: insecure download+install script).
The collision assist doesn’t prevent normal driving, it only activates >>> when things are about to go seriously wrong[2]; for almost everybody the >>> same is true of protected_regular, it only blocks anything when an
attack is underway.
protected_regular does prevent "normal driving" and it decidedly
'activates' in situations where nothing untoward is underway. I've
described an example of that.
You’re not in the “almost everybody”.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 152:45:42 |
| Calls: | 12,091 |
| Calls today: | 4 |
| Files: | 15,000 |
| Messages: | 6,517,652 |