linux-kernel - Re: [PATCH 1/5] WIP: Add syscall unlinkat

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]

Date:	Tue, 03 Feb 2015 16:18:50 -0800
From:	Alex Elsayed <eternaleye@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 1/5] WIP: Add syscall unlinkat_s (currently x86* only)

Al Viro wrote:

> On Tue, Feb 03, 2015 at 07:01:50PM +0100, Alexander Holler wrote:
> 
>> Yeah, as I've already admitted in the bug, I never should have use
>> the word secure, because everyone nowadays seems to end up in panic
>> when reading that word.
>> 
>> So, if I would be able to use sed on my mails, I would replace
>> unlinkat_s() with unlinkat_w() (for wipe) or would say that _s does
>> stand for 'shred' in the means of shred(1).
> 
> TBH, I suspect that the saner API would be something like
> EXT2_IOC_[SG[ETFLAGS, allowing to set and query that along with other
> flags (append-only, etc.).
> 
> Forget about unlink; first of all, whatever API you use should only _mark_
> the inode as "zero freed blocks" (or trim, for that matter).  You can't
> force freeing of an inode, so either you make sure that subsequent freeing
> of inode, whenever it happens, will do that work, or your API is
> hopelessly
> racy.  Moreover, when link has been removed it's too late to report that
> fs has no way to e.g. trim those blocks, so you really want to have it
> done
> _before_ the actual link removal.  And if the file contents is that
> sensitive, you'd better extend the same protection to all operations that
> free its
> blocks, including truncate(), fallocate() hole-punching, whatever.  What's
> more, if you divorce that from link removal, you probably don't want it as
> in-core-only flag - have it stored in inode, if fs supports that.
> 
> Alternatively, you might want to represent it as xattr - as much as I hate
> those, it might turn out to be the best fit in this case, if we end up
> with several variants for freed blocks disposal.  Not sure...
> 
> But whichever way we represent that state, IMO
> a) operation should be similar to chmod/chattr/setfattr - modifying
> inode metadata.
> b) it should affect _all_ operations freeing blocks of that file
> from that point on
> c) it should be able to fail, telling you that you can't do that for
> this backing store.

Well, chattr already has +s which means exactly this. It's just not 
respected by... anything. The 0/5 mentioned it, albeit briefly.

--
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/