From: Jesse Pollard <pollard@admin.navo.hpc.mil>
To: Bill Davidsen <davidsen@tmr.com>,
Linux-Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Filesystem Capabilities in 2.6?
Date: Wed, 6 Nov 2002 07:36:52 -0600 [thread overview]
Message-ID: <200211060736.52780.pollard@admin.navo.hpc.mil> (raw)
In-Reply-To: <Pine.LNX.3.96.1021105183722.20035A-100000@gatekeeper.tmr.com>
On Tuesday 05 November 2002 05:47 pm, Bill Davidsen wrote:
> On Sat, 2 Nov 2002, Linus Torvalds wrote:
> > There are two fairly trivial ways to do it:
> >
> > - put the actual data in the directory entry itself. This is efficient,
> > but not very easily extensible, since most directory structures have
> > serious size limitations.
>
> I think the arguments against having different capabilities for the same
> executable by different names have been made. It does seem that this would
> mean a symbolic link to the enabled directory entry would work and have
> capabilities, while a hard link to the inode would not?
>
> Being hard to understand is one source of security errors of the "I didn't
> mean to do that" type.
Not to mention what happens if a file gets lost - fsck puts it in the
lost+found directory, but without the protection specified by the owner.
> > - Make a new file type, and put just that information in the directory
> > (so that it shows up in d_type on a readdir()). Put the real data in
> > the file, ie make it largely look like an "extended symlink".
>
> I thought about symlink-like thngs when I was trying to envision an ACL by
> group, allowing control of a group other than the non-owner group to have
> more (or fewer) rights.
>
> > The latter approach is probably a bit too reminiscent of a Windows
> > "shortcut" aka LNK file to some people, but hey, maybe it's a good idea.
>
> The problem with any form of link by name is that there's no easy way to
> tell from the inode how many pointers there are, and from the link to tell
> when the link target has changed. I could envision security attacks based
> on changing the base file and having capabilities apply via the link.
>
> None of this is beyond implementation, but the idea of having something on
> a file inode certainly removes all attacks taking advantage of the link
> relationship. The best way to make something secure is to eliminate the
> need for it.
absolutely
--
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
next prev parent reply other threads:[~2002-11-06 13:32 UTC|newest]
Thread overview: 124+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-01 8:49 Rusty's Remarkably Unreliable List of Pending 2.6 Features Rusty Russell
2002-11-01 16:19 ` Karim Yaghmour
2002-11-02 6:32 ` Rusty Russell
2002-11-01 18:32 ` Filesystem Capabilities in 2.6? Dax Kelson
2002-11-01 19:05 ` Nicholas Wourms
2002-11-01 22:07 ` Olaf Dietsche
2002-11-01 23:25 ` Jan Harkes
2002-11-04 17:51 ` Mark H. Wood
2002-11-01 22:07 ` Olaf Dietsche
2002-11-01 22:59 ` Rusty Russell
2002-11-02 13:41 ` Olaf Dietsche
2002-11-02 7:06 ` Theodore Ts'o
2002-11-02 13:38 ` Olaf Dietsche
2002-11-02 18:18 ` Olaf Dietsche
2002-11-02 22:57 ` Bernd Eckenfels
2002-11-02 18:35 ` Dax Kelson
2002-11-06 1:07 ` Bill Davidsen
2002-11-02 18:47 ` Linus Torvalds
2002-11-02 23:02 ` Bernd Eckenfels
2002-11-02 23:11 ` Chris Wedgwood
2002-11-03 0:18 ` Rik van Riel
2002-11-03 0:22 ` Linus Torvalds
2002-11-03 0:43 ` Alexander Viro
2002-11-03 0:52 ` Alexander Viro
2002-11-04 13:02 ` Pavel Machek
2002-11-03 0:47 ` Rik van Riel
2002-11-03 1:53 ` Linus Torvalds
2002-11-03 1:05 ` David D. Hagood
2002-11-03 2:05 ` Linus Torvalds
2002-11-03 13:55 ` Olaf Dietsche
2002-11-05 8:47 ` Rogier Wolff
2002-11-05 10:50 ` Bernd Eckenfels
2002-11-03 1:27 ` Alan Cox
2002-11-03 2:43 ` Werner Almesberger
2002-11-03 12:46 ` Alan Cox
2002-11-03 0:56 ` Olaf Dietsche
2002-11-03 2:03 ` Linus Torvalds
2002-11-03 2:21 ` Alexander Viro
2002-11-03 3:23 ` Linus Torvalds
2002-11-03 3:35 ` Linus Torvalds
2002-11-03 4:28 ` Alexander Viro
2002-11-03 13:03 ` Alan Cox
2002-11-03 14:51 ` Alexander Viro
2002-11-03 16:50 ` Alan Cox
2002-11-03 16:56 ` Alexander Viro
2002-11-03 16:56 ` yodaiken
2002-11-03 18:13 ` Linus Torvalds
2002-11-03 18:25 ` yodaiken
2002-11-03 18:42 ` Linus Torvalds
2002-11-04 0:40 ` Rik van Riel
2002-11-03 7:36 ` Hacksaw
2002-11-03 8:59 ` Kai Henningsen
2002-11-03 10:50 ` Hacksaw
2002-11-04 8:55 ` Rando Christensen
2002-11-03 12:57 ` Alan Cox
2002-11-03 15:20 ` Bernd Eckenfels
2002-11-03 16:30 ` Ragnar Kjørstad
2002-11-03 16:40 ` Bernd Eckenfels
2002-11-03 17:10 ` Alan Cox
2002-11-09 20:11 ` Pavel Machek
2002-11-10 22:50 ` Bernd Eckenfels
2002-11-03 13:55 ` Olaf Dietsche
2002-11-03 3:50 ` Oliver Xymoron
2002-11-03 4:00 ` Dax Kelson
2002-11-03 4:10 ` Oliver Xymoron
2002-11-03 13:55 ` Olaf Dietsche
2002-11-03 4:20 ` Linus Torvalds
2002-11-03 4:37 ` Alexander Viro
2002-11-03 4:54 ` Linus Torvalds
2002-11-03 5:09 ` Alexander Viro
2002-11-03 5:39 ` Linus Torvalds
2002-11-03 6:37 ` Alexander Viro
2002-11-03 7:16 ` Dax Kelson
2002-11-03 9:18 ` Alexander Viro
2002-11-03 20:35 ` Michal Jaegermann
2002-11-04 9:25 ` Antti Salmela
2002-11-04 12:24 ` Olaf Dietsche
2002-11-04 14:39 ` Theodore Ts'o
2002-11-04 15:13 ` Jesse Pollard
2002-11-03 5:03 ` Oliver Xymoron
2002-11-03 5:25 ` Dax Kelson
2002-11-03 5:52 ` Linus Torvalds
2002-11-03 6:46 ` Alexander Viro
2002-11-03 12:53 ` Alan Cox
2002-11-03 13:52 ` Olaf Dietsche
2002-11-03 14:38 ` Alexander Viro
2002-11-03 16:01 ` Olaf Dietsche
2002-11-03 16:09 ` Alexander Viro
2002-11-03 12:51 ` Alan Cox
2002-11-03 21:02 ` Ryan Anderson
2002-11-03 3:36 ` [REPORT] current use of capabilities Dax Kelson
2002-11-03 13:57 ` Olaf Dietsche
2002-11-05 12:14 ` Andreas Gruenbacher
2002-11-03 4:04 ` Filesystem Capabilities in 2.6? Dax Kelson
2002-11-03 4:10 ` Alexander Viro
2002-11-03 5:31 ` Erik Andersen
2002-11-03 5:37 ` Dax Kelson
2002-11-03 5:42 ` Erik Andersen
2002-11-03 6:07 ` Dax Kelson
2002-11-03 22:24 ` Anders Gustafsson
2002-11-03 15:13 ` Bernd Eckenfels
2002-11-03 12:45 ` Alan Cox
2002-11-03 15:49 ` Patrick Finnegan
2002-11-04 15:00 ` Patrick Finnegan
2002-11-04 15:51 ` Olaf Dietsche
2002-11-04 16:53 ` Patrick Finnegan
2002-11-04 17:23 ` Olaf Dietsche
2002-11-03 13:30 ` Olaf Dietsche
2002-11-03 15:11 ` Bernd Eckenfels
2002-11-04 2:49 ` Jan Harkes
2002-11-04 14:50 ` Theodore Ts'o
2002-11-04 15:33 ` Alan Cox
2002-11-04 20:35 ` Ulrich Drepper
2002-11-04 21:50 ` Linus Torvalds
2002-11-04 14:58 ` Jesse Pollard
2002-11-05 23:47 ` Bill Davidsen
2002-11-06 13:36 ` Jesse Pollard [this message]
2002-11-05 4:14 ` Andreas Gruenbacher
2002-11-05 14:48 ` Olaf Dietsche
2002-11-05 15:05 ` Andreas Gruenbacher
-- strict thread matches above, loose matches on Subject: below --
2002-11-03 0:31 Albert D. Cahalan
2002-11-03 3:15 ` john slee
2002-11-06 0:00 ` Bill Davidsen
2002-11-05 0:11 Tom Reinhart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200211060736.52780.pollard@admin.navo.hpc.mil \
--to=pollard@admin.navo.hpc.mil \
--cc=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox