lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20060809104155.48ad3c77.froese@gmx.de>
Date:	Wed, 9 Aug 2006 10:41:55 +0200
From:	Edgar Toernig <froese@....de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Pekka Enberg <penberg@...helsinki.fi>, Pavel Machek <pavel@....cz>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	akpm@...l.org, viro@...iv.linux.org.uk, tytso@....edu,
	tigran@...itas.com
Subject: Re: [RFC/PATCH] revoke/frevoke system calls V2

Alan Cox wrote:
>
> Ar Llu, 2006-08-07 am 22:41 +0200, ysgrifennodd Edgar Toernig:
> >
> > Your implementation is much cruder - it simply takes the fd
> > away from the app; any future use gives EBADF.  As a bonus,
> 
> It needs to give -ENXIO/0 as per BSD that much is clear.

Ah, OK.  And not to forget select/poll.  (What about SIGHUP?)
I'm not sure though, whether it's really necessary to allow the
owner of a file to revoke fds - I would feel better if only root
(or someone with the right caps) could revoke fds/mappings.

> To use revoke() I must own the file
> If I own the file I can make it a symlink to a pty/tty pair
> I can revoke a pty/tty pair

With the EIO/EOF behaviour that's not a problem - apps that deal
with ttys have to expect that condition.


> > A serious question: What do you need this feature of revoking
> > regular files (or block devices) for?  Maybe my imagination
> > is lacking, but I can't find a use where fuser(1) (or similar
> > tools) wouldn't be as good or even better than revoke(2).
> 
> On a typical non-SELinux system with a typical desktop configuration
> (SELinux can effectively replace revoke) you need revoke on block
> devices in order to guarantee security

Hmm... which apps have an open fd on block devices?  Usually a
filesystem is mounted on the device and then there are no fds
to the block-dev involved.  Or do you expect the "fuser -m"
behaviour from revoke?  Afaics, that's not the case at the moment.
Which users have perms to access a block-dev anyway?

> There are specific cases where being able to revoke access to one of
> your files is useful as well, particularly if you are moving it from
> open permissions to private permissions. That one is to be honest much
> less interesting and it is easy enough to make our revoke()
> implementation return -EINVAL.

Hmm... then use fuser and kill the process instead of silently taking
away fds and mappings.


My summary: revoke on chars devs with EIO/EOF behaviour is ok.
            revoke on blocks devs is questionable
            revoke on regular files is wrong.

Ciao, ET.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ