executable but not readable

executable but not readable

[Christopher Huhn]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: executable but not readable

[Trond Myklebust]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: executable but not readable

[Christopher Huhn]

[-- Attachment #1: Type: text/plain, Size: 3262 bytes --]

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



[-- Attachment #2: Type: text/html, Size: 5901 bytes --]

Re: executable but not readable

[Trond Myklebust]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: executable but not readable

[Frank van Maarseveen]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: executable but not readable

[Trond Myklebust]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: executable but not readable

[Frank van Maarseveen]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: executable but not readable

[Trond Myklebust]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: executable but not readable

[Christopher Huhn]

[-- Attachment #1: Type: text/plain, Size: 869 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 1382 bytes --]