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]

Date:	Mon, 28 May 2007 22:00:54 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Pavel Machek <pavel@....cz>
Cc:	Valdis.Kletnieks@...edu, Toshiharu Harada <haradats@...il.com>,
	James Morris <jmorris@...ei.org>, casey@...aufler-ca.com,
	Andreas Gruenbacher <agruen@...e.de>,
	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

On May 28, 2007, at 16:38:38, Pavel Machek wrote:
> Kyle Moffett wrote:
>> I am of the opinion that adding a  "name" parameter to the file/ 
>> directory create actions would be useful.  For example, with such  
>> support you could actually specify a  type-transition rule  
>> conditional on a specific name or substring:
>>
>> named_type_transition sshd_t tmp_t:sock_file prefix "ssh-"  
>> ssh_sock_t;
>>
>> Useful options for matching would be "prefix", "suffix", "substr  
>> (start,len)".  "regex" would be nice but is sorta computationally  
>> intensive and would be likely to cause more problems than it solves.
>
> Could someone implement this? AFAICT that prevents SELinux from  
> being superset of AppArmor... Doing this should be significantly  
> simpler than whole AA, and hopefully it will end up less ugly, too.

Really it would need to extend all action-match items with new  
"named_" equivalents, and most callbacks would need to be extended to  
pass in an object name, if available.  On the other hand, with such  
support implemented then the AppArmor policy compilation tools could  
be transformed into a simple SELinux policy generator.  I estimate  
that the number of new lines of kernel code for such a modified  
SELinux would be 100x less than the kernel code in AppArmor.

Cheers,
Kyle Moffett

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