[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
>> fexecve() makes a lot of sense too. So would an flink(), [...]
> We'd want to be a bit careful about adding these as there are
> permission checks that are implied by specifying a path which you do
> not get with the f* calls mentioned.
Not per se, but the fd on the directory proxies for them, in that you
had to pass _its_ checks to get it. I'd say that having an O_EXEC fd
on a directory should be possible exactly when you can do lookups on a
path leading to that directory; similarly for FREAD and FWRITE for
directory read and modification. (IOW, if this isn't true, I think
something needs fixing.)
> Normally, these are not going to be terribly different but in the
> case of suid programs or chroot'ed programs, we'd want to analyse how
> we might change the security model.
Well, for set-ID programs, it's easy enough to just say the set-ID
program doesn't have to to use these calls if their characteristics
don't match the semantics it wants. For chrooted programs, this
actually strikes me as a useful facility. For example, using
SCM_RIGHTS to pass in a WRONLY fd onto an external directory could
allow a chrooted daemon to write a file into that directory _without_
(because the fd doesn't have O_EXEC) allowing the daemon to fchdir()
into it and thus escape the chroot.
This actually brings up an orthogonal point: it would be nice to be
able to downgrade a descriptor's capabilities by, for example, using
fcntl to set the open mode from O_RDWR to O_RDONLY....
If you don't want to go that way, you could just require that the fd
name a directory that's under the chroot in order for things to work.
Main Index |
Thread Index |