mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hauke Laging <mailinglisten@hauke-laging.de>
To: linux-kernel@vger.kernel.org
Subject: VFS: Dynamic umask for the access rights of linked objects
Date: Wed, 1 Mar 2006 03:28:41 +0100	[thread overview]
Message-ID: <200603010328.42008.mailinglisten@hauke-laging.de> (raw)

Hello,

I tried to send this to the VFS maintainer but the address I found on 
http://www.kernelnewbies.org/maintainers/ and in 
my /usr/src/linux/MAINTAINERS seems not to exist any more 
(viro@parcelfarce.linux.theplanet.co.uk).


The complete version of the following text ist avaiable at 
http://www.hauke-laging.de/ideen/symlink-umask/konzept_en.html


the problem
(At least) If applications store data in directories which are 
write-accessible by other users then symlink attacks become possible. A 
file is erased and replaced by a symlink. The (buggy) application can be 
abused if it can read or write the linked-to file but the abusing user 
cannot. These attacks are mostly denial of service attacks.


Solution
The kernel should be extended by a function (which can be enabled and 
disabled) which would solve the problem. The access rights of a symlink 
are ignored but its creator is stored. The kernel should do additional 
checks when determining whether a file system object can be accessed in 
the requested way:

- Is the accessed object a symlink?

- Has the creator of the symlink got the access rights which the respective 
process is requesting?

If the situation turns out to be critical then the kernel would deny the 
respective rights. The process cannot access the file via the symlink 
though it could have if it had tried to access it directly. The access 
rights of the symlink creator (through the whole path, not just for the 
file) would be used as a mask for the applications rights.


This approach does not solve every kind of this problem but should be quite 
easy to implement. I don't want this mail to get too long so I have left 
out some considerations about hard links. See the URL.


Best regards,

Hauke

             reply	other threads:[~2006-03-01  2:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-01  2:28 Hauke Laging [this message]
2006-03-01  2:45 ` Sam Vilain
2006-03-01  3:54   ` Hauke Laging
2006-03-01  4:21     ` Kyle Moffett
2006-03-01  7:59       ` Chris Wright
2006-03-02 16:11         ` Jiri Kosina
2006-03-01 16:33     ` Horst von Brand

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=200603010328.42008.mailinglisten@hauke-laging.de \
    --to=mailinglisten@hauke-laging.de \
    --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

all inboxes | Powered by JetHome®