Talk:Brainshare 2006

Transitive building of packages -- when building a package, all dependencies are automatically built as well. Over a million packages have been rebuilt.

Are being built in a way that they are all built the same.

Any package that has a src package can be rebuilt with the delivered bin package from novell. Most important criteria that oss is more secure than closed... vendor cannot plan added backdoors without customer knowing about it. Can't happen with closed source.
Peer review -- 4 guys review code changes and pass it if they all agree on the meaning of the code.

[edit]

Some Data

12 Servers, 250+ build clients
7 code bases
up to 9 architectures
3100 bin packages in 2000 src packages
Rebuild time for SLES9/CODE9 codebase: 7 hours
Minimum time from knowing about a vulnerability until patch availability for customer (testing/QA): 1.5 hours

Sometimes don't bother customers with very minor issues until next major release.

[edit]

Roles

Sponsor (IBM, HP, SGI)
Distributor (Novell/SUSE Linux Products GmbH)
Product (SLES8, SLES9)
Evaluator (atsec Inf Sec GmbH)
Cert Body (BSI, German Federal office for IT Sec, CCMRA accr.)

[edit]

Confinement

Application level security, platform hardening & confinement
- use of non-type-safe languages like C and C++ is a major reason
- Heap & stack overflows caused by insufficient bounds checks or format string errors (IIRC, this is the thing that AppArmor protects against... application level security)
Remedies
- least privilidge use

[edit]

AppArmor

Transparent
no conflicts with suse/novell maintenance
prebuilt profiles
runs on all filesystems.
has yast2 module
Immunix made AppArmor.. I've used Immunix before.

Security is considered to be a process and not a state. In other words, security is ongoing and never reaches an absolute state. They meet the guidelines and go further to complete the security process. Also Complex design and/or configuration contradicts security. Another showing of the KISS rule... ;) Read more about SELinux. It's confinement technology. It's installed in SLES9, but totally unsupported and turned off by default. No policys for it either.

[edit]

DL200 - Securely Locking Down Your SLES/OES Server

Single layer security -- root or non-root
VFS- virtual file system... doesn't matter what file system you are using, guarantees ability to talk to it.

[edit]

Interaction between user and kernel

Boundaries can be crossed by 3 different things:
1. System calls
2. Device Files
3. /proc
Kernel doesn't care about user names.. just user==0. Usernames exist on user side, not kernel.

[edit]

threats, attacks, remedy

Attacker knows objectives. Knows what he wants to do and expertise is known.
Owner calculates: value o fassets and potential damage vs. cost of effort. In our case, don't really know what to protect against.
Vendor does not know assets, attacker, expertise of owner or potential damages (data and installed applications.

[edit]

attack surface & toys

outside attack surface > exploiting a vulnerability > post-exploit luxury (shells, netcat)
obviously, more holes to enter, harder to keep people out.

[edit]

Threats/Attack surface

- remote vs. local
- networked vs. local
- client-side vs server-side

[edit]

Vulnerabilities

- heap- or stack-overflows, caused by insufficient bounds checks.. see LINUX SECURITY Session

[edit]

reducing threats: trust relationships

map trust relationships between your machines
- directory services
- IP access
- encrypted protocols ant protect integrity and confidentiality

Start at the root of trust!

Network Interfaces
- check interfaces
- /sbin/ip link; /sbin/ip addr
  - look at every interface and disable interface if not needed
  - compare /sbin/ip outputs to /etc/*****
network services
- check open ports:
- /bin/netstat -anpl|grep LISTEN
  - look at every process and disable as not needed
  - constrain access to services to only those peers that need them. use tcpwrappers (/etc/hosts.{allow,deny}) or netfilter (iptables, SuSEfirewall2/Yast2 firewall Module).**AppArmor has a third way
- verify findings remotely using
  - port scanner nmap -sS -v -O ...)
  - telnet <host> <port>
- inspect configuration of each service running
  - use "strace -tfwp <pid>", ltrace, "lsof -p <pid>" and "find /proc/<pid> -ls" to gather info
- data not present cannot be stolen!
- use only encrypted network protocols (SSL encaps, SSH, gpg email or IPSec-Tunnels)
network client software (not really experienced users)
- remove software that is not needed.
- do not allow use of non-system-owned software

---Tripwire--- tripwire is a way to check filesystem by way of some type of snapshot.

Enable logs. Reinstalled system is ultimately the solution to compromised system. Don't destroy access times by wading through the system on your own. Pull network plug on compromised system and move to another box. keep data on compromised system for restore. (what we did with ASD-SLES9 box.. :) Good for us.)

[edit]