Re: [RFC PATCH v1 1/2] fs: Add O_DENY_WRITE

On Mon, Aug 25, 2025 at 9:43=E2=80=AFAM Andy Lutomirski <[email protected]=
t> wrote:
>
> On Mon, Aug 25, 2025 at 2:31=E2=80=AFAM Micka=C3=ABl Sala=C3=BCn <mic@dig=
ikod.net> wrote:
> >
> > On Sun, Aug 24, 2025 at 11:04:03AM -0700, Andy Lutomirski wrote:
> > > On Sun, Aug 24, 2025 at 4:03=E2=80=AFAM Micka=C3=ABl Sala=C3=BCn <mic=
@digikod.net> wrote:
> > > >
> > > > On Fri, Aug 22, 2025 at 09:45:32PM +0200, Jann Horn wrote:
> > > > > On Fri, Aug 22, 2025 at 7:08=E2=80=AFPM Micka=C3=ABl Sala=C3=BCn =
<[email protected]> wrote:
> > > > > > Add a new O_DENY_WRITE flag usable at open time and on opened f=
ile (e.g.
> > > > > > passed file descriptors).  This changes the state of the opened=
 file by
> > > > > > making it read-only until it is closed.  The main use case is f=
or script
> > > > > > interpreters to get the guarantee that script' content cannot b=
e altered
> > > > > > while being read and interpreted.  This is useful for generic d=
istros
> > > > > > that may not have a write-xor-execute policy.  See commit a5874=
fde3c08
> > > > > > ("exec: Add a new AT_EXECVE_CHECK flag to execveat(2)")
> > > > > >
> > > > > > Both execve(2) and the IOCTL to enable fsverity can already set=
 this
> > > > > > property on files with deny_write_access().  This new O_DENY_WR=
ITE make
> > > > >
> > > > > The kernel actually tried to get rid of this behavior on execve()=
 in
> > > > > commit 2a010c41285345da60cece35575b4e0af7e7bf44.; but sadly that =
had
> > > > > to be reverted in commit 3b832035387ff508fdcf0fba66701afc78f79e3d
> > > > > because it broke userspace assumptions.
> > > >
> > > > Oh, good to know.
> > > >
> > > > >
> > > > > > it widely available.  This is similar to what other OSs may pro=
vide
> > > > > > e.g., opening a file with only FILE_SHARE_READ on Windows.
> > > > >
> > > > > We used to have the analogous mmap() flag MAP_DENYWRITE, and that=
 was
> > > > > removed for security reasons; as
> > > > > https://man7.org/linux/man-pages/man2/mmap.2.html says:
> > > > >
> > > > > |        MAP_DENYWRITE
> > > > > |               This flag is ignored.  (Long ago=E2=80=94Linux 2.=
0 and earlier=E2=80=94it
> > > > > |               signaled that attempts to write to the underlying=
 file
> > > > > |               should fail with ETXTBSY.  But this was a source =
of denial-
> > > > > |               of-service attacks.)"
> > > > >
> > > > > It seems to me that the same issue applies to your patch - it wou=
ld
> > > > > allow unprivileged processes to essentially lock files such that =
other
> > > > > processes can't write to them anymore. This might allow unprivile=
ged
> > > > > users to prevent root from updating config files or stuff like th=
at if
> > > > > they're updated in-place.
> > > >
> > > > Yes, I agree, but since it is the case for executed files I though =
it
> > > > was worth starting a discussion on this topic.  This new flag could=
 be
> > > > restricted to executable files, but we should avoid system-wide loc=
ks
> > > > like this.  I'm not sure how Windows handle these issues though.
> > > >
> > > > Anyway, we should rely on the access control policy to control writ=
e and
> > > > execute access in a consistent way (e.g. write-xor-execute).  Thank=
s for
> > > > the references and the background!
> > >
> > > I'm confused.  I understand that there are many contexts in which one
> > > would want to prevent execution of unapproved content, which might
> > > include preventing a given process from modifying some code and then
> > > executing it.
> > >
> > > I don't understand what these deny-write features have to do with it.
> > > These features merely prevent someone from modifying code *that is
> > > currently in use*, which is not at all the same thing as preventing
> > > modifying code that might get executed -- one can often modify
> > > contents *before* executing those contents.
> >
> > The order of checks would be:
> > 1. open script with O_DENY_WRITE
> > 2. check executability with AT_EXECVE_CHECK
> > 3. read the content and interpret it
>
> Hmm.  Common LSM configurations should be able to handle this without
> deny write, I think.  If you don't want a program to be able to make
> their own scripts, then don't allow AT_EXECVE_CHECK to succeed on a
> script that the program can write.
>
Yes, Common LSM could handle this, however, due to historic and app
backward compability reason, sometimes it is impossible to enforce
that kind of policy in practice, therefore as an alternative, a
machinism such as AT_EXECVE_CHECK is really useful.

> Keep in mind that trying to lock this down too hard is pointless for
> users who are allowed to to ptrace-write to their own processes.  Or
> for users who can do JIT, or for users who can run a REPL, etc.
>
The ptrace-write and /proc/pid/mem writing are on my radar, at least
for ChomeOS and Android.
AT_EXECVE_CHECK is orthogonal to those IMO, I hope eventually all
those paths will be hardened.

Thanks and regards,
-Jeff