Hello! I could not really find good information about the security features of the next 10.1 version from the Wiki. I'm personally very interested in 1) Easy access control systems (I do not know what these could be... but could be easier than current) 2) Easy way of sandboxing servers, like limiting SFTP to some folder and it's subfolders. 3) File and folder access auditing - very much needed feature in corporations!! A must have. 4) Scanning tools, like NMAP and Nessus (nmap is available from Guru YaST repository, but Nessus is not from anywhere AFAIK - except manually from nessus.org, I guess) So, can somebody elaborate on these features and their future in (OSS) SUSE Linux? -- HG.
On Wed, Feb 08, 2006 at 02:55:03PM +0200, HG wrote:
Hello!
I could not really find good information about the security features of the next 10.1 version from the Wiki. I'm personally very interested in 1) Easy access control systems (I do not know what these could be... but could be easier than current)
Thats a broad issue. We are using the traditional UNIX methods and replacing them ... well. What actually is the problem with the current one? Also AppArmor on top of the traditional UNIX way is possible.
2) Easy way of sandboxing servers, like limiting SFTP to some folder and it's subfolders.
Here the answer is AppArmor ;)
3) File and folder access auditing - very much needed feature in corporations!! A must have.
In SLES8 and SLES9 we included LAuS, a EAL/CAPP compliant audit system. For 10.1 and SLES 10 we include the upstream lightweight auditing framework, which is not yet EAL/CAPP compliant. (Its in the "audit" package.) However, some auditing capabilities are available already in this system.
4) Scanning tools, like NMAP and Nessus (nmap is available from Guru YaST repository, but Nessus is not from anywhere AFAIK - except manually from nessus.org, I guess)
nmap is on 10.1. nessus should be there too, but isn't on the CDs (Likely for space reasons.)
So, can somebody elaborate on these features and their future in (OSS) SUSE Linux?
Additionaly we have some lowlevel security things: - Continuing -D_FORTIFY_SOURCE=2 usage for all packages. glibc 2.4 protects more functions with this option. - glibc itself brings more consistency checks in its heap management, and start of pointer mangling of structs kept on the stack. - -fstack-protector use for critical libraries and binaries. (personally I do not consider that too important, the number of stack overflows is fortunately diminishing.) - Address space randomization enhancements: Unfortunately we have there only: - stack randomization (every platform, 10 bit) - mmap / shared library randomization on: i386 and amd64 in ia32 mode (with ulimit -s set), 10bit amd64 native (everytime), 19 bit (i think) Missing: - PIE randomization - Heap randomization - VDSO randomization Ciao, Marcus
Hi!
On 2/8/06, Marcus Meissner
On Wed, Feb 08, 2006 at 02:55:03PM +0200, HG wrote:
Hello!
I could not really find good information about the security features of the next 10.1 version from the Wiki. I'm personally very interested in 1) Easy access control systems (I do not know what these could be... but could be easier than current)
Thats a broad issue. We are using the traditional UNIX methods and replacing them ... well.
What actually is the problem with the current one?
Ah, I don't know. I guess the usage could be more simplified. I've tried to use ACL's, but it seems a bit complicated sometimes - of course using Samba in between makes it a little easier.
2) Easy way of sandboxing servers, like limiting SFTP to some folder and it's subfolders.
Here the answer is AppArmor ;)
I've been hearing about this... I'm just waiting for the 10.1 release so I can upgrade my home computer and start learning it. Hopefully there is some documentation with it also...
3) File and folder access auditing - very much needed feature in corporations!! A must have.
In SLES8 and SLES9 we included LAuS, a EAL/CAPP compliant audit system.
Yes, I've seen LAuS mentioned in some places.
For 10.1 and SLES 10 we include the upstream lightweight auditing framework, which is not yet EAL/CAPP compliant. (Its in the "audit" package.)
Why not LAuS? Is there something wrong with it?
However, some auditing capabilities are available already in this system.
Which system do you refer to?
4) Scanning tools, like NMAP and Nessus (nmap is available from Guru YaST repository, but Nessus is not from anywhere AFAIK - except manually from nessus.org, I guess)
nmap is on 10.1. nessus should be there too, but isn't on the CDs (Likely for space reasons.)
Sorry, seems that nmap was on 10.0 also, but Guru had a newer one. It doesn't matter that much if they are on the CD or not, as long as they are installable from YaST after adding some installation repositories. It's still quite specialized program compared to office or other desktop programs.
So, can somebody elaborate on these features and their future in (OSS) SUSE Linux?
Additionaly we have some lowlevel security things:
I'm quite confident in the progress of lowlevel securyti (although of course there is much to do always), but it's more those higher level features that are critical for many businesses to be able to manage and monitor the resources. (Although AppArmour sounds more like lowlevel, I guess).
Ciao, Marcus
Thanks. -- HG.
Thats a broad issue. We are using the traditional UNIX methods and replacing them ... well.
What actually is the problem with the current one?
Ah, I don't know. I guess the usage could be more simplified. I've tried to use ACL's, but it seems a bit complicated sometimes - of course using Samba in between makes it a little easier.
ACLs are supported on most of our filesystems now.
3) File and folder access auditing - very much needed feature in corporations!! A must have. In SLES8 and SLES9 we included LAuS, a EAL/CAPP compliant audit system. Yes, I've seen LAuS mentioned in some places.
For 10.1 and SLES 10 we include the upstream lightweight auditing framework, which is not yet EAL/CAPP compliant. (Its in the "audit" package.) Why not LAuS? Is there something wrong with it?
We never got it into the mainline kernel, due to some bad timing issues mostly. As we were finished doing it for SLES 9, the mainline kernel suddenly got its own audit system, which of course conflicted with LAuS. We never found the time and resources to push our stuff in there.
However, some auditing capabilities are available already in this system. Which system do you refer to?
The one in the mainline kernel. The userland is here: http://people.redhat.com/sgrubb/audit/ Mostly done by Redhat/IBM currently. Ciao, Marcus
Marcus, On Wednesday 08 February 2006 08:11, Marcus Meissner wrote:
...
What actually is the problem with the current one?
Ah, I don't know. I guess the usage could be more simplified. I've tried to use ACL's, but it seems a bit complicated sometimes - of course using Samba in between makes it a little easier.
ACLs are supported on most of our filesystems now.
Have the been added to (or enabled for) XFS?
...
Ciao, Marcus
Randall Schulz
Hi, On Wednesday 08 February 2006 08:25, Randall R Schulz wrote:
Marcus,
On Wednesday 08 February 2006 08:11, Marcus Meissner wrote:
...
What actually is the problem with the current one?
Ah, I don't know. I guess the usage could be more simplified. I've tried to use ACL's, but it seems a bit complicated sometimes - of course using Samba in between makes it a little easier.
ACLs are supported on most of our filesystems now.
Have the been added to (or enabled for) XFS?
This seems like such a simple factual question, requiring only a "yes" or "no" answer. Does no one know? RRS
On Wed, Feb 08, 2006 at 10:23:12PM -0800, Randall R Schulz wrote:
Hi,
On Wednesday 08 February 2006 08:25, Randall R Schulz wrote:
Marcus,
On Wednesday 08 February 2006 08:11, Marcus Meissner wrote:
...
What actually is the problem with the current one?
Ah, I don't know. I guess the usage could be more simplified. I've tried to use ACL's, but it seems a bit complicated sometimes - of course using Samba in between makes it a little easier.
ACLs are supported on most of our filesystems now.
Have the been added to (or enabled for) XFS?
This seems like such a simple factual question, requiring only a "yes" or "no" answer. Does no one know?
XFS supports ACLs, yes. Ciao, Marcus
Marcus, On Wednesday 08 February 2006 22:59, Marcus Meissner wrote:
On Wed, Feb 08, 2006 at 10:23:12PM -0800, Randall R Schulz wrote:
On Wednesday 08 February 2006 08:25, Randall R Schulz wrote:
On Wednesday 08 February 2006 08:11, Marcus Meissner wrote:
...
ACLs are supported on most of our filesystems now.
Have the been added to (or enabled for) XFS?
This seems like such a simple factual question, requiring only a "yes" or "no" answer. Does no one know?
XFS supports ACLs, yes.
Great, thanks. Do you know, offhand, at which release of SuSE Linux they were added to XFS? I know that in either 9.1 or 9.3 (the two previous releases I ran, with 10.0 being what I'm running now) XFS did not support FACLs. Now I see XFS in 10.0 does support them. (Yeah, I could have checked first...)
Ciao, Marcus
Randall Schulz
Hello, Am Mittwoch, 8. Februar 2006 17:00 schrieb HG:
Ah, I don't know. I guess the usage could be more simplified. I've tried to use ACL's, but it seems a bit complicated sometimes
Starting with KDE 3.5, you can set ACLs using the file properties dialog (permissions - extended permissions - add entry/edit entry [1]). This new "extended permissions" button in KDE may be overlooked often, but it is an important improvement :-) Regards, Christian Boltz [1] translated back from german, wording may therefore differ -- Es ist eben nicht trivial korrekten Code zu schreiben. exit(-1); syslog(LOG_ERROR, "Can't exit.\n"); [Lutz Donnerhacke in dclp]
Hello!
On 2/8/06, Christian Boltz
Hello,
Am Mittwoch, 8. Februar 2006 17:00 schrieb HG:
Ah, I don't know. I guess the usage could be more simplified. I've tried to use ACL's, but it seems a bit complicated sometimes
Starting with KDE 3.5, you can set ACLs using the file properties dialog (permissions - extended permissions - add entry/edit entry [1]). This new "extended permissions" button in KDE may be overlooked often, but it is an important improvement :-)
Good to hear! I may just be what I'm looking for. -- HG.
Hello, Am Mittwoch, 8. Februar 2006 14:04 schrieb Marcus Meissner:
On Wed, Feb 08, 2006 at 02:55:03PM +0200, HG wrote: [...]
2) Easy way of sandboxing servers, like limiting SFTP to some folder and it's subfolders.
Here the answer is AppArmor ;)
I guess the better answer would be "scponly" or "rssh" which I already added to productivity wishlist some time ago. Of course there's nothing wrong with additional protection using AppArmor, but AFAIK AppArmor can't restrict (chroot) a customer to his webspace as FTP (unencrypted, I know), scponly or rssh can do. Regards, Christian Boltz --
Kann man das für alle MUAs sagen? Nein, wohl nicht. Es gibt todkranke, kranke (die durch richtige Konfiguration wieder gesund werden) und gesunde MUAs. [> Ratti und Mathias Bauer in suse-linux]
Hi!
On 2/8/06, Christian Boltz
Of course there's nothing wrong with additional protection using AppArmor, but AFAIK AppArmor can't restrict (chroot) a customer to his webspace as FTP (unencrypted, I know), scponly or rssh can do.
I hope it isn't so. I've been looking for easy solution since I once had a commercial SSH on Windows where SFTP-was chrooted with one checkbox -- HG.
On 2006-02-08 17:35:12 +0100, Christian Boltz wrote:
I guess the better answer would be "scponly" or "rssh" which I already added to productivity wishlist some time ago.
did you ever look at the code of both? both had recently the same type of security hole. atm i say thanks no. JFYI i did the scponly package once but atm i wouldnt put it on a product.
Of course there's nothing wrong with additional protection using AppArmor, but AFAIK AppArmor can't restrict (chroot) a customer to his webspace as FTP (unencrypted, I know), scponly or rssh can do.
$ rpm -ql pam-modules | grep chroot /etc/security/chroot.conf /lib/security/pam_chroot.so /usr/share/doc/packages/pam/modules/README.pam_chroot-0.6 hope this helps darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org
participants (5)
-
Christian Boltz -
HG -
Marcus Meissner -
Marcus Rueckert -
Randall R Schulz