linux-kernel - Re: [AppArmor 01/41] Pass struct vfsmount to the inode

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: <653438.15244.qm@web36612.mail.mud.yahoo.com>
Date:	Sun, 27 May 2007 09:12:18 -0700 (PDT)
From:	Casey Schaufler <casey@...aufler-ca.com>
To:	Cliffe <cliffe@...et.net.au>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

--- Cliffe <cliffe@...et.net.au> wrote:

>  >> On the other hand, if you actually want to protect the _data_, then 
> tagging the _name_ is flawed; tag the *DATA* instead.
> 
> Would it make sense to label the data (resource) with a list of paths 
> (names) that can be used to access it?

Program Access Lists (PALs) were* a feature of UNICOS. PALs could
contain not only the list of programs that could use them, but what
attributes the processes required as well. Further, you could
restrict or raise privilege based on the uid, gid, MAC label, and
privilege state of the process during exec based on the PAL. 

> Therefore the data would be protected against being accessed via 
> alternative arbitrary names. This may be a simple label to maintain and 
> (possibly to) enforce, allowing path based confinement to protect a 
> resource. This may allow for the benefits of pathname based confinement 
> while avoiding some of its problems.

Yep, but you still have the label based system issues, the classic
case being the text editor that uses "creat new", "unlink old",
"rename new to old". When the labeling scheme is more sopisticated
than "object gets label of subject" label management becomes a major
issue.

> Obviously this would not protect against a pathname pointing to 
> arbitrary data

Protecting special data is easy. Protecting arbitrary data is the
problem.

> Just a thought.

Not a bad one, and it would be an easy and fun LSM to create.
If I were teaching a Linux kernel programming course I would
consider it for a class project.

-----
* I have used the past tense here in spite of the many
  instances of UNICOS still in operation. I don't believe
  that there is any current development on UNICOS.

Casey Schaufler
casey@...aufler-ca.com
-
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/