Sun Security Blog
Security
|
CVE-2009-0159 describes a security issue in the ntpq(1M) daemon which could allow remote NTP servers to crash the ntpq program or to execute arbitrary code when ntpq is used to query them. Sun has examined the implementation of the ntpq(1M) command that is shipped with Solaris and has determined that although the affected code is present and has been fixed as Sun bug ID 6831824, it is not possible to exploit this issue on Solaris to execute arbitrary code or to crash the ntpq command. tags: security solaris vulnerability Permalink |Interim Security Reliefs (ISR) that fix CVE-2008-1447 (VU#800113) in Solaris 8 and 9 are available from http://sunsolve.sun.com/tpatches for the following releases: SPARC Platform
These ISRs deliver BIND 9 with the fix for CVE-2008-1447. Solaris 8 and 9 use BIND version 8. In that version it is not possible to implement needed fix because of design of this fix. Also, BIND 8 is already end of life (EOL) according ISC. Sun is currently working on a patch to release the fixed BIND version 9 for Solaris 8 and 9 (replacing the EOL BIND 8 there). Changing the release from BIND 8 to BIND 9 is not a trivial task and therefore the patches to address these are still in progress. Users MUST completely re-configure BIND as per instructions in /usr/lib/dns/migration.txt in order to use the new BIND 9 and the fixes that these patches deliver. This migration document is shipped as part of the IDRs at SUNWcsu/reloc/usr/lib/dns/migration.txt Please refer to Sun Alert 239392 "Security Vulnerability in the DNS Protocol may lead to DNS Cache Poisoning", Sun Alert 240048 Update to Sun Alert 239392 and US-CERT Vulnerability Note VU#800113 for more details on this vulnerability. NOTE: Interim Security Relief (ISRs) are designed to address the concerns identified herein. Sun has limited experience with these (ISRs) due to their interim nature. As such, you should only install the ISRs on systems meeting the configurations described above. Sun may release full patches at a later date, however, Sun is under no obligation whatsoever to create, release, or distribute any such patch. tags: alert bind cve-2008-1447 security solaris vu#800113 Permalink | Comments [0]Solaris 10 11/06 now has a Common Criteria EAL4+ certification for CAPP/RBACPP/LSPP. For full details see the press release. Details of all Solaris Common Criteria certifications are available on the security certifications page. - Darren tags: capp common criteria lspp rbacpp solaris trusted Permalink | Comments [0]
The removal of the Solaris Data Encryption Kit has been quite a difficult and long process for us, we are taking a different approach for Solaris 10 and for OpenSolaris. Valerie Bubb has info on how it has been done for Solaris 10 and is also currently running codereview for the OpenSolaris variant which is the full fix for this.
-
Darren
Permalink
|
Comments [1]
Trusted Extensions binaries have been part of Solaris since the 3rd update release of Solaris 10. Over the weekend Trusted Extensions entered a new and very exciting era. Not only is it now part of the Solaris 10 binary product but there were two signficant changes.
- Darren tags: opensolaris security solaris trusted Permalink | Comments [0]
As mentioned I was visiting the USA last week, and stopped-in
on my
former colleague
and friend
Keith Watson,
who introduced me to the delights of
MCPlus+ ("EmCeePlusPlus") -
a nerdcore / geek-rap act who
sing about cryptography and maths.
Cryppies will want to listen to track 4 off the album 'Algorhythms', viz Alice and Bo b. w00t.
tags: mcplus+ mcplusplus nerdcore security slotd solaris Permalink | Comments [2]A couple of podcasts on various security topics can be found on sun.com/security The Systemic Security recording is of Hal Stern talking to Glenn Brunette about what we're building, documenting and sharing to (help) make everything that gets deployed more secure. In the Solaris podcast they are joined by Darren Moffatt, and chat about what security features we have in Solaris (crypto, Trusted Extensions, RBAC...) and what will be coming in the future. Ellyptic Curve Cryptography is the topic of the third podcast, this time with Hal discussing matters withVipul Gupta. After an overview of what ECC is, they look at the interoperability aspects of these algorithms. Update: To hear another voice -- Joel Weise's -- on one of the topics Hal raised in those podcasts there's the systemic security "Net Talk" programme. -Bart tags: cryptography ecc podcast security solaris trusted Permalink | Comments [1]
This is a posting in the
Security
Community 'Reference' Category ; the function of postings that are
placed in this category is to aggregate links to other, useful
postings in a single meta-posting which can be referenced via a
link in the Security Community Blog sidebar, and which will be
re-posted on the blog each time it is refreshed by a member of the
security community.
This posting is a list of security video blogs which have been posted to the community.
tags: rbac security slotd solaris training videos Permalink | Comments [2]If the video is the 5 cent tour of Solaris RBAC then this is probably the book for the "self-guided walk through RBAC". This is a transcript of an early draft version of the video (one which I canned as looking at 20 minutes of someone typing is just not that interesting...) -Bart The Self-Guided Walk Through Solaris RBAC To make use of Solaris' Role Based Access Control you can use any "out of the box" version since Solaris 8, although to make use of fine-grained privileges you'd need either Trusted Solaris 8, Solaris 10, or more recent, such as Solaris Express. The only preparation (optional, really) is to enable Solaris Auditing - which I recommend doing anyway, though it's important to note that for most systems logging only a limited set of events will do. So: on a newly installed system the only account that can be used is the root account, so log in as root. The first thing to do is to add (at least one) user account, so that someone other than root can log in and use the system. Here we create two accounts, one of which will be permitted to assume the root role: # useradd -u 1001 -g staff -d /home/bart -s /bin/ksh -c "Bart who is also the admin" -m bart # useradd -u 1002 -g staff -d /home/joe -s /bin/ksh -c "Joe who is just a user" -m joe # passwd bart # passwd joe Now there are two user accounts on the system, as well as the root account. The problem with that root account is that anybody who has the password can walk up to this system and log in as root -- and, even with full auditing enabled, there'd only be a list of things done by root, with no way of knowing who actually ran those commands... With RBAC there's an easy way to fix this: make root a role -- because fundamentally that's what roles are: from the system's point of view they're just regular accounts (with the expected entries in /etc/passwd and /etc/shadow), that cannot directly log in. The only difference between a role and a user account is one little item in /etc/user_attr: it says "type=role" for a role, and "type=normal" for a user - which is the default, so if there's no entry the account is considered a regular account. The thing that differentiates roles from users in practice is a little PAM module pam_roles that checks wether an account is a role, and if so it denies direct log-in, and denies su by unauthorised users. Making root into a role can be done with one command: # usermod -K type=role rootthough doing just this and then logging out would make it impossible to become root (though when booting the system in single-user the restriction that the account can't be used directly is not enforced. If nobody should ever be permitted to become root without an audit trail it's probably best to set an OBP or BIOS password, and have that be stored somewhere where the admins need to sign a log to retrieve it...), so (at least) one of the users should be permitted to assume the root role. # usermod -R root bart When now someone tries to log-in to the system as root the system won't let them, even if they have the right password -- they'll be shown an error message indicating that "Roles can only be assumed by authorized users". If our other user (Joe) tries to su to root he'll get the same error message; only Bart would be permitted (with root's password) to become root. This is one of the obvious differences between sudo and RBAC: in sudo users generally authenticate using their own password, not the root account's password. One of the big advantages of using roles is that an auditor can later determine who assumed which role, and - if auditing is configured to log this - what they did as that role. This is pretty much the most basic use of roles that one can have, and in many circumstances be sufficient: only authorised users can become root, and there is a log of who did what on the system. Now: you can also create other accounts as roles, but that in itself would not be very interesting: they'd be normal accounts, that can't do anything special -- so besides giving people controlled access to a set of files (those owned by the role) there'd be not much else those roles can be used for. There may be some people that need to perform some tasks without being given complete root access, or they may have root access when needed but it would be convenient if some administrative commands could be used without the extra step of assuming a role. In Solaris RBAC both of these are possible by assigning "rights profiles" (sometimes also called "rights", sometimes also called "profiles") to those accounts: assigning it to a user account gives that user the extra magic abilities that come with the profile, assigning a profile to a role provides those powers to users who are authorized to assume the role. Most of the profile configuration files live in /etc/security, with the exception of /etc/user_attr - which we saw earlier. A rights profile, described in prof_attr, is a container that can contain other rights profiles (so we can create hierarchies of profiles), plus possibly some authorizations, and maybe a list of commands and their attributes. Let's start with those commands and their attributes: there is a list of commands in /etc/security/exec_attr and for each entry we can specify a number of things :
(A brief refresher on privileges: Traditionally in Unix when a process tries to do something like accessing devices, configuring the system, or opening a file for which it doesn't have permission, the kernel would check the process' credentials and if the process was run with userid 0 (the root account) then the system call in question would succeed. With privileges the kernel now doesn't merely check the userid but instead checks a new process attribute, which is the privilege set.) With RBAC we can now specify individual commands and the privileges they need, so we can let a user execute one or two commands with magical extra privileges, whilst all other commands run just the way they always have. The exec_attr configuration file shows which profile an entry applies to, plus the command in question and the security attributes of the command (effective UID/GID, real UID/GID, and a list of privileges). If you don't specify privileges or UIDs/GIDs then those will be inherited from the parent process, just like any other command that a user executes. In short a user can be allowed to run a couple commands with extra privileges -- perhaps, to change some of the graphics settings, to renew a DHCP lease, or to reset a print queue -- to help things run smoothly. If there's a need to store files for a specific task, then assigning the rights profiles to a role is probably more appropriate, as the role's home directory can be used as a task-specific storage area. A role would usually be given a function-specific list of commands to execute, for instance to support an operator, DBA, or auditor. If it is mandated that a user enter a password before utilising magic powers then the only way of doing so is to assign the magic powers to a role, requiring the users to assume that role for the function specified. If secondary authentication is not needed and if there's no need for shared storage (i.e. the role's home directory) then I recommend you just assign the rights profile to the user. There is one constraint when assigning commands to users or roles: in order to get those commands to run with different UIDs or GIDs or with extra privileges they will need to be executed from a "profile shell" -- /usr/bin/pfsh, /usr/bin/pfcsh, /usr/bin/pfksh -- or via the sudo-like pfexec command. These are the tools which know about rights profiles, and they ensure that the correct attributes are set when the command is executed. A role gets a profile shell by default, but users who have special rights profiles will need to be given a different shell, or they must run the commands via pfexec (To reiterate for people familiar with sudo: pfexec is the closest equivalent on Solaris, but note that it doesn't do secondary authentication and doesn't currently limit command line options to any of the commands). As an example we'll allow Bart to review the audit logs on the system, and will grant him the appropriate rights profile: (As root or other administrative account:) # usermod -P "Audit Review" bart ...and now Bart can run things like "/usr/sbin/praudit" (either by invoking the command via pfexec, or by running it from pfsh, pfcsh, or pfksh). NB all users are given the "Basic Solaris User" rights profile by default as specified in /etc/security/policy.conf; it allows all users to run all commands they have access to -- but without any special attributes. Taking this away means that an account which uses a profile shell will be allowed to only run those commands listed in the output of profiles(1) and no others. Besides specifying commands and their attributes in a rights profile we can also list authorizations. Authorizations are defined in /etc/security/auth_attr in a hierarchical manner. When a user is assigned a root or subroot of that hierarchy they get all authorizations which exist under it. Authorizations are attributes of users -- they're not "process attributes" like privileges, instead they are something that the kernel doesn't know about. They are used by individual applications to determine wether the application should perform some action on behalf of a user. Even though privileges permit finer grained control over what applications are permitted to do, you can't use them to control modification of records within a file. Using application to mediate access to those records and authorizations in that application you can get the level of control that you desire. One of the applications that makes extensive use of authorizations in this manner is the Solaris Management Console: it may permit one account (e.g. the system administrator) to create users, while not permitting that account to set the user's password or audit mask (which might be done by someone else, such as the security manager). The Solaris Service Management Facility is one of the more recent users of authorizations which permits allowing a user or role to restart a service without permitting that user or role to reconfigure the service - and without the need to allow that user or role direct access to the process or its configuration files. Authorizations are attributes of a user, so they can be assigned directly to a user (in which case they're listed in etc/user_attr), but they can also be assigned indirectly as part of a rights profile - in which case they're listed in /etc/security/prof_attr. And, really, that's pretty much all there is to Solaris RBAC. In summary, there are users and there are roles -- which are just like users, except that they tend to be used for specific tasks (system administration, operations and so on), and can only be "assumed" via su rather than accessed directly. Both types of accounts are defined in /etc/passwd & /etc/shadow, and their account type is specified in /etc/user_attr. In the latter file we grant users and roles authorizations, so that applications and tools which are authorization-aware (such as Solaris Management Console and the Service Management Facility) will perform their magic on behalf of authorized staff. In user_attr we also assign "rights profiles" which may add extra authorizations and which will permit those users and roles to execute particular commands with extra magic privileges or different UIDs or GIDs, if they choose to do so via pfexec or a use of a profile login shell. tags: introduction rbac solaris Permalink | Comments [1]Sometimes when trying to fix a problem or writing some piece of code I realise I only have a very vague idea how to go about attacking it. Usually there's a fair bit of documentation, but lacking a clear idea of what exactly I need I have no idea where to start reading... And that's why it's nice to have water coolers (be it the real ones in the break room or the virtual ones on IM or IRC): you can usually find someone who knows more about the stuff that puzzles you, who will happily explain how things fit together, providing the big picture so that now you know where to start. Having for a while now dabbled in things Trusted Solaris and Trusted Extensions I've also become more familiar with Solaris Role-Based Access Control, so I've been the one to provide the 5 minute "big picture" about those topics to a couple colleagues... so I thought it might be useful to do something similar for people that I tend to not run into at the water cooler... This 5 cent tour of Solaris Role-Based Access Control is a five minute overview of the main bits and pieces of RBAC. It's not meant to replace the documentation: it's a rough guide, providing enough background to maybe have a go at making root a role on your system, or to help find your way in the man pages and maybe set up your system for dual-role administration... A brief overview of the main concepts and components of Solaris RBAC (Role-Based Access Control).
The video is also available in QuickTime (30MB) or Shockwave Flash (3MB). I'm considering doing one of these around Trusted Extensions; if you'd find that interesting please do leave a comment (comments about this video are welcome too, obviously). -Bart
tags: introduction rbac solaris video Permalink | Comments [10]
So I posted this:
A man is going on vacation (ie: on holiday) - and he's worried about the possibility of someone breaking into his house whilst he's away; so he checks all the window locks from inside the house, steps outside, walks around the house to inspect for anything he's missed - checking that patio doors, etc, are locked - then locks his front door and drives off. What's he done wrong?...which is my usual schtick for trying to explain the importance of doing things in the right order, because even if you have the right security-ingredients you can still mess up by not using them properly, or not laying them out in a sensible manner. I was blown away by some of the creativity that was provided in the responses - the person who went for the jugular and got my typically sought-for answer was Andy Paton: While he was busy checking the windows and backdoor he left the front door unlocked!!...which is the obvious flaw in the process; it's astonishing how many people completely miss that. That said - and thank you Andy - this being an open question there is always room for a different perspective, eg: trojan horses: ...the systemic: ...the architectural and integrational: ...and the slightly tongue-in-cheek operational risk: ...all of these are legitimate and interesting answers; even the last one by analogy of the occasion I saw someone enable system-auditing in a particularly nitpicky mode, only to see the machine crash from filling its root partition two days later. This is related to the reason I generally put /var/log and /var/adm on a partition completely separate from root and the normal /var - it's a signature perversity of a Muffett-specified machine, but your machine is at less risk from log-flooding. So, next time I have to stand up and give this talk to somebody, I'll have something extra to say. Thank you folks, and thank you for sharing. Thank you also to Tom for this little gem which made me smile: He should check that the front door is locked, from the inside? My father's old front door you could open the lock through the letterbox using a handily located small crowbar....which just goes to prove that security can be perfectly acceptable if it fits your environment; I still know places where nobody bothers to lock their doors when they go out for the day, but nowadays they seem somehow fewer and further between... -alec
tags: architecture integration security slotd solaris Permalink | Comments [1]
So Techdirt writes:
Last week, security expert Bruce Schneier caused a bit of a stir when he said that there shouldn't be a security industry. While his comment engendered a lot of debate, it really wasn't a particularly radical statement. As he's made clear in his latest Wired column, all he meant was that IT vendors should be building security directly into their products, rather than requiring customers to purchase security products and services separately. ...citing Bruce as reported at Silicon.COM:
"The fact this show even exists is a problem. You should not have to come to this show ever. [...] We shouldn't have to come and find a company to secure our email. Email should already be secure. We shouldn't have to buy from somebody to secure our network or servers. Our networks and servers should already be secure." ...and I think he is right, as I find Bruce generally is. My experience bears this out - I have friends who ask "What Anti-Virus Software / Malware Detector / Intrusion Detection System Should I Use?" - and in none of these cases do I actually have an answer for them. Sometimes they must really wonder what I do for a living, if I'm a "security expert" and don't know what AV software to use. It's true, however. Given what I use at home (Solaris, Mac, Linux, and an solitary and rarely booted XP system), plus the manner in which I connect to the Internet (NAT/firewall built in to my DSL router) and the fact that I understand the value of keeping security patches up to date, not running services/daemons unless they are necessary, and cycling WEP and login passwords occasionally, with all that in place I don't have to use any specialist security software at all. Instead I use what tools I have available with my network hardware and software platforms - generally some form of Unix - making sure they're all properly deployed. Sometimes I get a hacker knocking on my door, I've certainly seen a few attempts in my logfiles, but it's not something I fret about since there's very little exposed to attack, and of the latter it's all generally well-maintained. So why should I worry? Beats me. The Silicon.COM article also contains this quote from Graham Cluley at Sophos:
"I can't imagine there ever being a 100 per cent secure operating system because a vital component of programming that operating system is human." Well yes, Gray, you're right, but one of the things you've left unstated is that there is no such absolute thing as 100% security. Security is relative: 100% security means "100% Adequate" security, that the security features you've deployed are proportionate to the exposure you make in transacting with the rest of the network, plus mitigation of any risks you face in terms of availability ("I can't access my Gmail! Argh!") or physical security ("Someone stole my laptop!") No, there won't ever be a 100% secure system, but people who care are currently able to get systems which are adequately "secure by default" and if they know how to use and maintain those systems properly then yes, there won't be a security industry any more. - alec
tags: by default schneier secure security slotd solaris Permalink | Comments [1]
OK - so I was at a very interesting customer today, and conversation swung around to "defense-in-depth" and that bastion of IT security, the firewall.[1]
We were in the midst of some on-the-fly rearchitecture discussion (read: "if we replumb it all in a more elegant fashion, what needs to be fixed or added in order to make it safe?") and it turned out that an extra firewall to demarcate a line between some public and private machines, would make matters a lot more secure. "It'll cost a lot, this new firewall", says their long-haired sysadmin. "Why", says I? "Firewall license" says he, and names a largeish four-figure number. Eek. That's more than the hardware! So one of the things I've never understood - and I've told him this - is why the "Cult Of Firewall" is such that only a "dedicated box or appliance" running "genuine firewall software" for which $$$$$$ are paid, is what people go running towards whenever firewalls are mentioned. Sure, in an enterprise context where people bandy words like "five nines" (ie: 99.999% uptime) - or "extreme(ly) high availability", or where you need "management consoles" - then do buy an enterprise solution where you might be able to sue the vendor if it blows up. But if you are a small-to-medium organisation with your own in-house pet geeks, then why not take advantage of general-purpose functionality of general-purpose operating systems and deploy Solaris, Linux or *BSD as a firewall? Consider your choice carefully, minimise it to the utmost, but it'd be a lot cheaper and often perfectly adequate and more than adequately performant. I started at Sun in 1992 and if I had had more business sense back then, and if I had had more money, then I would have cottoned on to the number of SparcStation2's that I was buying, to act as "routers" for our intranet. This observation might have led me to invest in Cisco and its dedicated routers, and made me a tidy profit. Oh well. But the thing about IT security is that "what goes around, comes around". Maybe it's time for the comeback of the general-purpose operating system, in tiny tasks, on more-than-adequately-powerful hardware? - alec
--
tags: ipfilter security slotd solaris sun Permalink | Comments [3]
This is a really quick one - keep an eye on Darren's blog; he's posted the first installment in a series which will discuss the relative configurations and merits of "sudo" versus RBAC in Solaris, and is attracting the attentions of Powerbroker users, and perhaps others who are intrigued at the notion of delegating small parts of root privilege to ordinary users.
The number of times I've dealt with customer queries about that sort of thing, I feel that I'll soon be citing his blog like holy writ.
-alec
tags: security slotd solaris sudo Permalink | Comments [0]Historically, Trusted Solaris was a completely separate environment from "regular" Solaris. The Solaris 10 11/06 production release finally broke the mould, when Trusted Extensions integrated into the main Solaris release. Granted, the packages which need to be installed on the top of an unlabelled Solaris 10 install still need to be installed using an extra install tool, but you'll nonetheless find them on the regular distribution media under the Solaris_10/ExtraValue/CoBundled directory, right alongside the SunVTS hardware validation test suite. Configuring everything once the packages are in place is a more interesting proposition, but there's a good recipe here (for laptops). We make no bones about the fact that Trusted Solaris began life as an engineering project for the US Government, first went live 17 years ago, and has seen little use in the commercial world (with one or two notable exceptions) by its nature as a separate product with military heritage ever since - however, now that it's no longer a separate product, we believe that the time is right for commercial adoption. To this effect, we've been looking at some of the areas in the commercial world where its capabilities have a natural fit. So far, the partial list looks like:
Update: If we extend this a little further, we have: Any organisation where leakage of internal data is an issue could benefit from having a simple, two-label system of "Public" dominated by "Internal", where "Public" is the Internet connection and "Internal" is the Intranet. If all users are (as is the default) denied permission to downgrade data, then it becomes much more unlikely that internal data will leak. Giving users the ability to upgrade data by default still allows external data to be brought internal. This works well even when organisations do not differentiate between classifications of internal materials, and the Safe Browsing mechanism comes into its own, when web sites on the intranet need to make pointers to materials in the wider world.Press Officer and Auditor roles could also be created, which would potentially be the only roles allowed to downgrade data as part of the external release process. In educational establishments, denying the ability to upgrade and downgrade data means that while a number of websites can readily be viewed (assuming filtering software is already in place on the Internet link), data can't readily be plagiarised using cut and paste from external sources into essays, etc. Also, if Public and Internal zones are installed as whole-root rather than sparse-root zones, such that careful use of pkgrm can subsequently be used to deny access to internal tools (such as IM) in an external context, so cyber-bullying could be more readily tracked; bullies wouldn't be able to create anonymous / pseudonymous external accounts "on the fly" from which to abuse their victims. As well as co-location facilities, law firms may wish to extend their "duty of care" capability, in terms of ensuring segregation of client data, by having a compartmented label per client. If you have some more ideas, please add them in a comment :-)
tags: extensions security slotd solaris trusted Permalink | Comments [0] |
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
