linux-kernel - Re: ACLs

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:	Sat, 05 Aug 2006 01:54:48 +0200
From:	RazorBlu <razorblu@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: ACLs

Kyle Moffett wrote:
> You're quite wrong about SELinux; it _is_ part of the kernel.  
> Admittedly it requires a policy to be built and loaded from userspace, 
> but your "ACLs" would require some ACL utilities to apply those from 
> userspace.
That is true, but is it included in every stable release of the kernel 
(by default)? And why aren't more distributions using it (the popular 
ones - for example, I know Mandriva uses grsecurity).
> In any case SELinux is an extremely powerful model; you can define 
> your arbitrary RBAC+TE state machine and constraints, then the kernel 
> applies it to your system; as simple (or horribly complicated, as the 
> case may be) as that.
And what are your feelings on SELinux still being "under research"? Can 
such a system be used in a production environment, when it has not been 
declared a completely mature system by its creators?
> Here's a better security model:  SELinux lets you give root access to 
> everybody and still have a 100% secure system (although it's not 
> really recommended).  Google around for the public SSH-accessible 
> SELinux testbeds with root's password set to "password" or "1234" or 
> whatever and feel free to log in and have a look.  Besides, we do have 
> POSIX ACLs on files; if that's what you're looking for, but that's not 
> extensible enough to cover processes too.
A 100% secure system except for the files that sshd has access to, 
correct? If global access is allowed to root, but it is locked down to 
sshd, then anyone who logs in as root can only modify those files that 
sshd has access to... Or is there a part of the puzzle that I am 
missing? I had not heard of those testbeds before, but I would like to 
see how they are set up.

"Besides, we do have POSIX ACLs on files; if that's what you're looking 
for, but that's not extensible enough to cover processes too." - Precisely.
> Cheers,
> Kyle Moffett
>
Regards,


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