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: <200706091101.JAB31303.PTNNSGtM@I-love.SAKURA.ne.jp>
Date:	Sat, 9 Jun 2007 11:01:41 +0900
From:	Tetsuo Handa <from-lsm@...ove.SAKURA.ne.jp>
To:	david@...g.hm
Cc:	linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation,pathname matching

Hello.

David Lang wrote:
> as I understand it SELinux puts one label on each file, so if you have 
> three files accessed by two programs such that
> program A accesses files X Y
> program B accesses files Y Z
> 
> then files X Y and Z all need separate labels with the policy stateing 
> that program A need to access labels X, Y and program B needs to access 
> files Y Z
> 
> extended out this can come close to giving each file it's own label. AA 
> essentially does this and calls the label the path and computes it at 
> runtime instead of storing it somewhere.

I tried to give each file it's own label, but I couldn't do it.
http://sourceforge.jp/projects/tomoyo/document/nsf2003-en.pdf
There are many elements that forms too strong barrier between pathname and labels,
such as bind-mounts, hard links, newly created files, renamed files, temporary files and so on.
So I gave up giving each file a label that can be used as an identifier,
and took an approach to forbid unneeded mount operations, unneeded link operations,
unneeded renaming operations to keep the pathname represent it's own identifier as much as possible.

Thanks.
-
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