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: <FD1C999C-AF16-40AC-B0E1-87441E8FF078@mac.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ