Hi alltogether,
(I'm sorry to bother you with this but I could not find any clues yet)
Szenario:
* a server exports shell scripts to clients with root_squash
* these scripts have -rwx-r-x--x (root:root) rights (executable but
not readable)
The clients are able to run these scripts with server kernel version 2.4.20.
Now we switched the server to 2.4.25 and get "permission denied" on
execution.
As far as I comprehend file permissions this should never have worked?
But nobody ever noticed as long as it worked and the guy in charge says:
"This was always a feature on VMS." :-P
This assumption is confirmed by the fact that "su nobody -c
/usr/local/sbin/mkclonediskremupdate" executed on the server does not
work either.
Are these observations correct or am I missing something?
Sorry for the silly question.
Regards,
Christopher
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
P=E5 to , 25/03/2004 klokka 13:00, skreiv Christopher Huhn:
> The clients are able to run these scripts with server kernel version 2.4.=
20.
> Now we switched the server to 2.4.25 and get "permission denied" on=20
> execution.
On page 99, RFC1813 states explicitly that
A similar problem has to do with paging in an executable
program over the network. The operating system usually checks
for execute permission before opening a file for demand
paging, and then reads blocks from the open file. In a local
UNIX file system, an executable file does not need read
permission to execute (pagein). An NFS version 3 protocol
server can not tell the difference between a normal file read
(where the read permission bit is meaningful) and a demand
pagein read (where the server should allow access to the
executable file if the execute bit is set for that user or
group or public). To make this work, the server allows
reading of files if the uid given in the call has either
execute or read permission on the file, through ownership,
group membership or public access. Again, this departs from
correct local file system semantics.
So if the server is denying read access in 2.4.25, then someone must
have introduced a bug...
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi Trond,
thanks first for your prompt answer.
Trond Myklebust wrote:
>P? to , 25/03/2004 klokka 13:00, skreiv Christopher Huhn:
>
>
>>The clients are able to run these scripts with server kernel version 2.4.20.
>>Now we switched the server to 2.4.25 and get "permission denied" on
>>execution.
>>
>>
>On page 99, RFC1813 states explicitly that
>
> A similar problem has to do with paging in an executable
> program over the network.
>
The point is that I'm not talking about (ELF) executables but shell
scripts!
IMHO in local semantics the shell interpreter cannot execute scripts the
executor has not read permissions for (How should he without beeing
setuid root?).
I made these tests with ls and a script ls.sh that simply calls ls :
-rwxr-x--x 1 root root 43784 Mar 18 2002 /bin/ls
-rwxr-x--x 1 root root 30 Mar 26 10:20 /bin/ls.sh
nobody@client[2.4.25-gsi]# /bin/ls
... works ...
nobody@client[2.4.25-gsi]# /bin/ls.sh
/bin/ls.sh: /bin/ls.sh: Permission denied
and on the server:
nobody@server[2.4.20]# /bin/ls
... works ...
nobody@server[2.4.20]# /bin/ls.sh
/bin/ls.sh: /bin/ls.sh: Permission denied
> To make this work, the server allows
> reading of files if the uid given in the call has either
> execute or read permission on the file.
>
This happens over NFS:
root@client[2.4.25-gsi]# /nfs/mount/2.4.20/ls
...works ...
root@client[2.4.25-gsi]# /nfs/mount/2.4.20/ls.sh
... works ...
root@client[2.4.25-gsi]# cat /nfs/mount/2.4.20/ls.sh
... works (so no security improvements by setting sensitive scripts
--x over nfs ) ...
*but*
root@client[2.4.25-gsi]# /nfs/mount/2.4.25/ls
... works ...
root@client[2.4.25-gsi]# /nfs/mount/2.4.25/ls.sh
/nfs/mount/2.4.25/ls.sh: /nfs/mount/2.4.25/ls.sh: Permission denied
and to complete this:
root@client[2.4.20]# /nfs/mount/2.4.25/ls
... works ...
root@client[2.4.20]# /nfs/mount/2.4.25/ls.sh
/nfs/mount/2.4.25/ls.sh: /nfs/mount/2.4.25/ls.sh: Permission denied
Btw: Nor ls neither ls.sh can be cat'ed in these constellations.
>Again, this departs from
> correct local file system semantics.
>
>
With 2.4.25 it seems to comply with the local semantics rather than
RFC1813.
>So if the server is denying read access in 2.4.25, then someone must
>have introduced a bug...
>
>
That's what it seems, even though I like it the way it is now :-)
These are our specs:
Vanilla kernels 2.4.20 with
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
# CONFIG_ROOT_NFS is not set
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
# CONFIG_NFSD_TCP is not set
# CONFIG_NCPFS_NFS_NS is not set
and 2.4.25 with
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
# CONFIG_NFS_DIRECTIO is not set
CONFIG_ROOT_NFS=y
CONFIG_NFSD=m
CONFIG_NFSD_V3=y
CONFIG_NFSD_TCP=y
# CONFIG_NCPFS_NFS_NS is not set
The exports are rw,root_squash
The mount options are rw,sync,v3,rsize=8192,wsize=8192,hard,intr,udp,lock
We are using the nfs-common and nfs-kernel-server debian packages
version 1.0-2woody1.
Regards,
Christopher
P=E5 fr , 26/03/2004 klokka 05:48, skreiv Christopher Huhn:
> The point is that I'm not talking about (ELF) executables but shell
> scripts!=20
> IMHO in local semantics the shell interpreter cannot execute scripts
> the executor has not read permissions for (How should he without
> beeing setuid root?).
That is irrelevant: the server knows nothing about the existence of
shell scripts. The point in the RFC is that the server should be looking
at both the "executable" and the "read" bits when deciding whether or
not to grant read access to the client.
In NFSv3, the ACCESS call should then be used to decide whether or not
the client is allowed to open the file for execution (and for reading if
that is required). Unfortunately ACCESS is not implemented in the stock
Linux 2.4.x kernel.
Otherwise the client can only look at the mode bits in order to try to
make the same decision. Of course that will fail to work properly anyway
if the server has a different uid/gid mapping scheme to the client.
However if you really want to prevent OTHER+GROUP from reading and
executing your shell scripts, then "chmod 500 /bin/ls.sh" is your
simplest solution. That does the same thing on both the local and remote
filesystems.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Fri, Mar 26, 2004 at 02:17:51PM -0500, Trond Myklebust wrote:
>
> In NFSv3, the ACCESS call should then be used to decide whether or not
> the client is allowed to open the file for execution (and for reading if
> that is required). Unfortunately ACCESS is not implemented in the stock
> Linux 2.4.x kernel.
So the kernel does its own permission checking on the client side
for executables _knowing_ that it is going to execute the file but
unfortunately the interpreter has to open the file by itself and that
fails.
But from a different perspective:
Being able to create a (non-setuid) executable which cannot be read
for security reasons looks very weak to me unless of course it is not
possible to let it dump core, strace (ptrace) it, open /proc/... files
etc. But is that all actually the case in 2.6?
--
Frank
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
P=E5 lau , 27/03/2004 klokka 07:17, skreiv Frank van Maarseveen:
> On Fri, Mar 26, 2004 at 02:17:51PM -0500, Trond Myklebust wrote:
> >=20
> > In NFSv3, the ACCESS call should then be used to decide whether or not
> > the client is allowed to open the file for execution (and for reading i=
f
> > that is required). Unfortunately ACCESS is not implemented in the stock
> > Linux 2.4.x kernel.
>=20
> So the kernel does its own permission checking on the client side
> for executables _knowing_ that it is going to execute the file but
> unfortunately the interpreter has to open the file by itself and that
> fails.
No... The kernel should do permission checking for execute, then opens
the file for reading (overriding the read permissions since this is the
kernel).
Unfortunately, the server is broken, and failing to follow RFC1813 when
it comes to allowing reads on executables.
> But from a different perspective:
>=20
> Being able to create a (non-setuid) executable which cannot be read
> for security reasons looks very weak to me unless of course it is not
> possible to let it dump core, strace (ptrace) it, open /proc/... files
> etc. But is that all actually the case in 2.6?
Sounds like a good test of the 2.6 VFS. Have you tried it?
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Sun, Mar 28, 2004 at 06:46:51PM -0500, Trond Myklebust wrote:
> P=E5 lau , 27/03/2004 klokka 07:17, skreiv Frank van Maarseveen:
> > On Fri, Mar 26, 2004 at 02:17:51PM -0500, Trond Myklebust wrote:
> > >=20
> > > In NFSv3, the ACCESS call should then be used to decide whether or not
> > > the client is allowed to open the file for execution (and for reading=
if
> > > that is required). Unfortunately ACCESS is not implemented in the sto=
ck
> > > Linux 2.4.x kernel.
> >=20
> > So the kernel does its own permission checking on the client side
> > for executables _knowing_ that it is going to execute the file but
> > unfortunately the interpreter has to open the file by itself and that
> > fails.
>=20
> No... The kernel should do permission checking for execute, then opens
> the file for reading (overriding the read permissions since this is the
> kernel).
>=20
> Unfortunately, the server is broken, and failing to follow RFC1813 when
> it comes to allowing reads on executables.
I don't understand this. The server doesn't see the difference between
a read for "read" purposes and a read for "execute" purposes IIRC. How
can the server then be broken?
>=20
> > But from a different perspective:
> >=20
> > Being able to create a (non-setuid) executable which cannot be read
> > for security reasons looks very weak to me unless of course it is not
> > possible to let it dump core, strace (ptrace) it, open /proc/... files
> > etc. But is that all actually the case in 2.6?
>=20
> Sounds like a good test of the 2.6 VFS. Have you tried it?
um, no, that's why I asked it. If security fails here and if it's
insolvable then it is a reason to drop the client side ACCESS check in 2.6
for read versus execute permission because it wouldn't buy you anything.
--=20
Frank
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
P=E5 su , 28/03/2004 klokka 18:59, skreiv Frank van Maarseveen:
> >=20
> > Unfortunately, the server is broken, and failing to follow RFC1813 when
> > it comes to allowing reads on executables.
>=20
> I don't understand this. The server doesn't see the difference between
> a read for "read" purposes and a read for "execute" purposes IIRC. How
> can the server then be broken?
Read the paragraph I quoted earlier in this thread from RFC1813. The
server is supposed to allow READ if the executable bit is set.
The ACCESS call should, however, act exactly like the local
sys_access(), and so should return an error if the user asks for READ
permission.
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Hi again,
Trond Myklebust wrote:
>The point in the RFC is that the server should be looking
>at both the "executable" and the "read" bits when deciding whether or
>not to grant read access to the client.
>...
>
>
>However if you really want to prevent OTHER+GROUP from reading and
>executing your shell scripts, then "chmod 500 /bin/ls.sh" is your
>simplest solution. That does the same thing on both the local and remote
>filesystems.
>
>
I'm totally aware of the fact that this approach to enhance the security
is dysfunctional and pretty lame [sigh].
Anyway, it was done like this in ancient days - and never worked but
never did any harm either.
Now it's not working anymore and the only thing changed is the kernel.
So to get back to my initial question: *Is this a NFS bug?* Or has maybe
something else changed in the kernel?
Regards,
Christopher