2015年2月

建议用户尽快升级

Canonical发布新 OpenJDK 7 的安全公告,它已经提交到Ubuntu 14.04 LTS和Ubuntu 14.10 的仓库中。该更新修复了大量的问题和漏洞。

Ubuntu维护者已经升级了仓库中的OpenJDK包,并且含有大量的修复。这是一个重要的更新,其涵盖了少量的库。

安全公告中说“OpenJDK JRE中发现了一些信息泄露、数据完整性和可用性的漏洞。攻击者可以利用这些通过网络执行拒绝服务或者泄露信息。”

同样,“OpenJDK JRE中发现了关于信息泄露和完整性的漏洞。攻击者可以利用这点通过网络泄露敏感信息。”

这里有几个漏洞被开发者确认,并且由维护人员解决。关于该问题的详细描述,你可以参考Canonical的安全通告。建议用户尽快升级系统。

这个漏洞只要你升级到最新的openjdk 7相关的包就可以修复。要应用该补丁,用户需要运行升级管理程序。通常上,一个标准系统更新就会安装必要的更新。所有java相关的程序需要重新启动。


via: http://linux.softpedia.com/blog/OpenJDK-7-Vulnerabilities-Closed-in-Ubuntu-14-04-and-Ubuntu-14-10-471605.shtml

本文发布时间:29 Jan 2015, 16:53 GMT

作者:Silviu Stahie 译者:geekpi 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

是的,你没看错。极简 Linux 发行版CrunchBang Linux 已经消失了

CrunchBang Linux,被大家所熟知的缩写标志“#!”,其基于Debian和Openbox窗口管理器。这个黑色主题的 Linux 发行版是许多资深 Linux用户的选择。

CrunchBang 因为 “不再有继续下去的价值” 而消失了

公告称,CrunchBang将不在继续开发,项目的领头人Philip Newborough说他在开始这个项目的时候,Linux 世界和现在不同。他指出那时在这种发行版还没有‘竞争’,但是随着Linux发行版的进步,如Lubuntu,Crunchbang这样的发行版就不具备原来的价值了。

对于任何十年前使用Linux的人而言,我想他们都会看到事物在不断发展。虽然一些事情一直保持不变,还有一些的变化超出了认知。这称之为进步。对于大部分事物而言,进步是一件好事。也就是说当进步发生时,一些事物落后了。对于我而言,CrunchBang就是我需要抛弃的东西。我抛弃它的原因是我真的认为它不再具有任何价值了,虽然我还可以因为一些多愁善感的原因把它留下来,但是我不认为那些使用原生Debian用户还有兴趣了。

CrunchBang消失之后会怎么样?

就像Pear OS那样,CrunchBang论坛仍将在线。现在仍可以下载但是不久的将来就会停止。Philip对他即将面对的新的项目和工作感到很激动。我希望他今后工作顺利。很难过见到一个像CrunchBang这样好的Linux发行版的消失。


via: http://itsfoss.com/crunchbang-linux-dead/

作者:Abhishek 译者:geekpi 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

问题:

假如说,使用32位的整型会溢出,在不考虑使用长整型的情况下,如果我们只需要表示2的40次方范围内的数,是否可以利用某些40位长的数据类型来表示呢?这样的话,每个整型数就可以节省24位的空间。

如果可以,该怎么做?

需求是:我现在必须处理数以亿计的数字,所以在存储空间上受到了很大的限制。

回答:

可以是可以,但是……

这种方法的确可行,但这么做通常没什么意义(因为几乎没有程序需要处理多达十亿的数字):

#include <stdint.h> // 不要考虑使用long long类型
struct bad_idea
{
    uint64_t var : 40;
};

在这里,变量var占据40位大小,但是这是以生成代码时拥有非常低的运行效率来换取的(事实证明“非常”二字言过其实了——测试中程序开销仅仅增加了1%到2%,正如下面的测试时间所示),而且这么做通常没什么用。除非你还需要保存一个24位的值(或者是8位、16位的值),这样你皆可以它们放到同一个结构中。不然的话,因为对齐内存地址产生的开销会抵消这么做带来的好处。

在任何情况下,除非你是真的需要保存数以亿计的数字,否则这样做给内存消耗带来的好处是可以忽略不计的(但是为了处理这些位字段的额外代码量是不可忽略的!)。

说明:

在此期间,这个问题已经被更新了,是为了说明实际上确实有需要处理数以亿计数字的情况。假设,采取某些措施来防止因为结构体对齐和填充抵消好处(比如在后24位中存储其它的内容,或者使用多个8位来存储40位),那么这么做就变得有意义了。

如果有十亿个数,每个数都节省三个字节的空间,那么这么做就非常有用了。因为使用更小的空间存储要求更少的内存页,也就会产生更少的cache和TLB不命中和内存缺页(单个缺页会产生数以千万计的指令 [译者注:直译是这样,但语义说不通!])。

尽管上面提到的情况不足以充分利用到剩余的24位(它仅仅使用了40位部分),如果确实在剩余位中放入了有用的数据,那么使用类似下面的方法会使得这种思路就管理内存而言显得非常有用。

struct using_gaps
{
    uint64_t var           : 40;
    uint64_t useful_uint16 : 16;
    uint64_t char_or_bool  : 8;  
};

结构体大小和对齐长度等于64位整型的大小,所以只要使用得当就不会浪费空间,比如对一个保存10亿个数的数组使用这个结构(不考虑使用指定编译器的扩展)。如果你不会用到一个8位的值,那么你可以使用一个48位和16位的值(giving a bigger overflow margin)。

或者以牺牲可用性为代价,把8个64位的值放入这样的结构体中(或者使用40和64的组合使得其和满足320)。当然,在这种情况下,通过代码去访问数组结构体中的元素会变得非常麻烦(尽管一种方法是实现一个operator[]在功能上还原线性数组,隐藏结构体的复杂性)。

更新:

我写了一个快速测试工具,只是为了获得位字段的开销(以及伴随位字段引用的重载操作)。由于长度限制将代码发布在gcc.godbolt.org上,在本人64位Win7上的测试结果如下:

运行测试的数组大小为1048576
what       alloc   seq(w)  seq(r)  rand(w)  rand(r)  free
-----------------------------------------------------------
uint32_t    0      2       1       35       35       1
uint64_t    0      3       3       35       35       1
bad40_t     0      5       3       35       35       1
packed40_t  0      7       4       48       49       1

运行测试的数组大小为16777216
what        alloc  seq(w)  seq(r)  rand(w)  rand(r)  free
-----------------------------------------------------------
uint32_t    0      38      14      560      555      8
uint64_t    0      81      22      565      554      17
bad40_t     0      85      25      565      561      16
packed40_t  0      151     75      765      774      16

运行测试的数组大小为134177228
what        alloc  seq(w)  seq(r)  rand(w)  rand(r)  free
-----------------------------------------------------------
uint32_t    0      312     100     4480     4441     65
uint64_t    0      648     172     4482     4490     130
bad40_t     0      682     193     4573     4492     130
packed40_t  0      1164    552     6181     6176     130

我们看到,位字段的额外开销是微不足道的,但是当以友好的方式线性访问数据时伴随位字段引用的操作符重载产生的开销则相当显著(大概有3倍)。在另一方面,随机访问产生的开销则无足轻重。

这些时间表明简单的使用64位整型会更好,因为它们在整体性能上要比位字段好(尽管占用更多的内存),但是显然它们并没有考虑随着数据集增大带来的缺页开销。一旦程序内存超过RAM大小,结果可能就不一样了(未亲自考证)。


via:stackoverflow

作者:DamonMichael Kohne 译者:KayGuoWhu 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

在Linux用户社区中, 很多人每年都会期待来自 LinuxQuestions.org 细致可靠的年度问卷调查报告。如同Susan在她的报告中指出的那样, 今年的结果着重于调查网站读者心中最棒的开源项目。 这份报告目前已经完成。 在LinuxQuestions的大多数人都是“专家级”的用户, 他们经常在网站上在线回答Linux新手们的提问。

在Susan所作的报告的附加内容里, 你可以看到由“专家”们对开源世界的关注点分布。

你也可以在这里找到一份较为精美的调查问卷总结图.这里呈现了网站投票得出的最佳Linux发行版, 可以看到Mint和Slackware平分了半壁江山:

而下图则是网站票选出的得出的最佳云项目。值得注意的是, LinuxQuestions的用户群体给予了ownCloud项目极高的评价。 你一定得亲自去看看调查结果的详情, 也看看 Susan 关于各项目“赢家”的总结, 还有一堆精美的图表


via: http://ostatic.com/blog/linuxquestions-survey-results-surface-top-open-source-projects

作者:Sam Dean 译者:jerryling315 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

首先,Linux中国祝贺读者 2015羊年春节快乐,万事如意! 。下面开始这个新年版审计工具的介绍。

安全防护是首先要考虑的问题。为了避免别人盗取我们的数据,我们需要时刻关注它。安全防护包括很多东西,审计是其中之一。

我们知道Linux系统上有一个叫 auditd 的审计工具。这个工具在大多数Linux操作系统中是默认安装的。那么auditd 是什么?该如何使用呢?下面我们开始介绍。

什么是auditd?

auditd(或 auditd 守护进程)是Linux审计系统中用户空间的一个组件,其负责将审计记录写入磁盘。

安装 auditd

Ubuntu系统中,我们可以使用 wajig 工具或者 apt-get 工具 安装auditd。

按照下面的说明安装auditd,安装完毕后将自动安装以下auditd和相关的工具:

  • auditctl : 即时控制审计守护进程的行为的工具,比如如添加规则等等。
  • /etc/audit/audit.rules : 记录审计规则的文件。
  • aureport : 查看和生成审计报告的工具。
  • ausearch : 查找审计事件的工具
  • auditspd : 转发事件通知给其他应用程序,而不是写入到审计日志文件中。
  • autrace : 一个用于跟踪进程的命令。
  • /etc/audit/auditd.conf : auditd工具的配置文件。

首次安装 auditd 后, 审计规则是空的。

可以使用以下命令查看:

$ sudo auditctl -l

以下我们介绍如何给auditd添加审计规则。

如何使用auditd

Audit 文件和目录访问审计

我们使用审计工具的一个基本的需求是监控文件和目录的更改。使用auditd工具,我们可通过如下命令来配置(注意,以下命令需要root权限)。

文件审计

$ sudo auditctl -w /etc/passwd -p rwxa

选项 :

  • -w path : 指定要监控的路径,上面的命令指定了监控的文件路径 /etc/passwd
  • -p : 指定触发审计的文件/目录的访问权限
  • rwxa : 指定的触发条件,r 读取权限,w 写入权限,x 执行权限,a 属性(attr)

目录审计

使用类似的命令来对目录进行审计,如下:

$ sudo auditctl -w /production/

以上命令将监控对 /production 目录 的所有访问。

现在,运行 auditctl -l 命令即可查看所有已配置的规则。

下面开始介绍审计日志。

查看审计日志

添加规则后,我们可以查看 auditd 的日志。使用 ausearch 工具可以查看auditd日志。

我们已经添加规则监控 /etc/passwd 文件。现在可以使用 ausearch 工具的以下命令来查看审计日志了。

$ sudo ausearch -f /etc/passwd
  • -f 设定ausearch 调出 /etc/passwd文件的审计内容

下面是输出 :

time->Mon Dec 22 09:39:16 2014

type=PATH msg=audit(1419215956.471:194): item=0 name="/etc/passwd" inode=142512 dev=08:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL

type=CWD msg=audit(1419215956.471:194): cwd="/home/pungki"

type=SYSCALL msg=audit(1419215956.471:194): arch=40000003 syscall=5 success=yes exit=3 a0=b779694b a1=80000 a2=1b6 a3=b8776aa8 items=1 ppid=2090 pid=2231 auid=4294967295 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=4294967295 comm="sudo" exe="/usr/bin/sudo" key=(null)

下面开始解读输出结果。

  • time : 审计时间。
  • name : 审计对象
  • cwd : 当前路径
  • syscall : 相关的系统调用
  • auid : 审计用户ID
  • uid 和 gid : 访问文件的用户ID和用户组ID
  • comm : 用户访问文件的命令
  • exe : 上面命令的可执行文件路径

以上审计日志显示文件未被改动。

以下我们将要添加一个用户,看看auditd如何记录文件 /etc/passwd的改动的。

time->Mon Dec 22 11:25:23 2014

type=PATH msg=audit(1419222323.628:510): item=1 name="/etc/passwd.lock" inode=143992 dev=08:01 mode=0100600 ouid=0 ogid=0 rdev=00:00 nametype=DELETE

type=PATH msg=audit(1419222323.628:510): item=0 name="/etc/" inode=131073 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=PARENT

type=CWD msg=audit(1419222323.628:510): cwd="/root"

type=SYSCALL msg=audit(1419222323.628:510): arch=40000003 syscall=10 success=yes exit=0 a0=bfc0ceec a1=0 a2=bfc0ceec a3=897764c items=2 ppid=2978 pid=2994 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="chfn" exe="/usr/bin/chfn" key=(null)

我们可以看到,在指定的时间,/etc/passwd ** 被root用户(uid =0, gid=0)在/root目录下修改。/etc/passwd 文件是使用/usr/bin/chfn** 访问的。

键入 man chfn 可以查看有关chfn更多的信息。

下面我们看另外一个例子。

我们已经配置auditd去监控目录 /production/ 了。这是个新目录。所以我们用ausearch去查看日志的时候会发现什么都没有。

下一步,使用root账户的ls命令列出 /production/ 下的文件信息。再次使用ausearch后,将会显示一些信息。

time->Mon Dec 22 14:18:28 2014 type=PATH msg=audit(1419232708.344:527): item=0 name="/production/" inode=797104 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL type=CWD msg=audit(1419232708.344:527): cwd="/root" type=SYSCALL msg=audit(1419232708.344:527): arch=40000003 syscall=295 success=yes exit=3 a0=ffffff9c a1=95761e8 a2=98800 a3=0 items=1 ppid=3033 pid=3444 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=4294967295 comm="ls" exe="/bin/ls" key=(null)

和上一个一样,可以得出root账户使用ls命令访问了/production/目录,ls命令的文件目录是 /bin/ls

查看审计报告

一旦定义审计规则后,它会自动运行。过一段时间后,我们可以看看auditd是如何帮我们跟踪审计的。

Auditd提供了另一个工具叫 aureport 。从名字上可以猜到, aureport 是使用系统审计日志生成简要报告的工具。

我们已经配置auditd去跟踪/etc/passwd文件。auditd参数设置后一段时间后,audit.log 文件就创建出来了。

生成审计报告,我们可以使用aureport工具。不带参数运行的话,可以生成审计活动的概述。

$ sudo aureport

如上,报告包含了大多数重要区域的信息。

上图可以看出有 3 次授权失败。 使用aureport,我们可以深入查看这些信息。

使用以下命令查看授权失败的详细信息:

$ sudo aureport -au

从上图可以看出,由两个用户在特定的时间授权失败。

如果我们想看所有账户修改相关的事件,可以使用-m参数。

$ sudo aureport -m

Auditd 配置文件

我们已经添加如下规则:

  • $ sudo auditctl -w /etc/passwd -p rwxa
  • $ sudo auditctl -w /production/

现在,如果确信这些规则可以正常工作,我们可以将其添加到/etc/audit/audit.rules中使得规则永久有效。以下介绍如何将他们添加到/etc/audit/audit.rules中去。

最后,别忘了重启auditd守护程序

# /etc/init.d/auditd restart

# service auditd restart

总结

Auditd是Linux上的一个审计工具。你可以阅读auidtd文档获取更多使用auditd和工具的细节。例如,输入 man auditd 去看auditd的详细说明,或者键入 man ausearch 去看有关 ausearch 工具的详细说明。

请谨慎创建规则。太多规则会使得日志文件急剧增大!


via: http://linoxide.com/how-tos/auditd-tool-security-auditing/

作者:Pungki Arianto 译者:shipsw 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

Kodi,原名就是大名鼎鼎的XBMC,发布了开发代号为Helix的最新版本14。感谢官方XMBC提供的PPA,现在可以很简单地在Ubuntu14.04中安装了。

有些人可能还不了解Kodi,它是一个媒体中心软件,支持所有平台,如Windows、Linux、 Mac, Android等。此软件拥有全屏的媒体中心,可以管理所有音乐和视频,不单支持本地文件还支持网络播放,如Tube、Netflix、 Hulu, Amazon Prime和其他流媒体服务商。

在 Ubuntu 14.04 和 Linux Mint 17 中安装 XBMC 14 Kodi Helix

再次感谢官方的PPA,让我们可以轻松安装Kodi 14。支持Ubuntu 14.04、Ubuntu 12.04、Linux Mint 17、Pinguy OS 14.04、Deepin 2014、LXLE 14.04、Linux Lite 2.0, Elementary OS 以及其他基于 Ubuntu 的 Linux 发行版。

打开终端(Ctrl+Alt+T)然后使用下列命令。

sudo add-apt-repository ppa:team-xbmc/ppa
sudo apt-get update
sudo apt-get install kodi

需要下载大约100MB,在我看来,这不是很大。若需安装解码插件,使用下列命令:

sudo apt-get install kodi-audioencoder-* kodi-pvr-*

从 Ubuntu 中移除 Kodi 14

从系统中移除 Kodi 14,使用下列命令:

sudo apt-get remove kodi

同样也应该移除PPA软件源:

sudo add-apt-repository --remove ppa:team-xbmc/ppa

我希望这篇简单的文章可以帮助到你在Ubuntu、Linux Mint 和其他 Linux 版本中轻松安装 Kodi 14。你是怎么发现 Kodi 14 Helix 的?

你有没有使用其他的媒体中心来作为 XBMC 的替代?可以在下面的评论区分享你的观点。


via: http://itsfoss.com/install-kodi-14-xbmc-in-ubuntu-14-04-linux-mint-17/

作者:Abhishek 译者:Vic020/VicYu 校对:Caroline

本文由 LCTT 原创翻译,Linux中国 荣誉推出