Last month, I wrote about confining the user with SELinux. I explained that–as of Fedora 9–SELinux supports the concept of the confined user and comes with 5 confined user types defined.

• guest_t – Terminal login, nosetuid, nonetwork, noxwindows, noexec in homedir
• xguest_t – X Windows Login and terminal login, nosetuid, nonetwork, noexec in homedir
• user_t - X Windows Login and terminal login, nosetuid, noexec in homedir
• staff_t - X Windows Login and terminal login, nosetuid except sudo
• unconfined_t – Full login, able to run with almost all privs as with SELinux disabled.

These confined users are a great starting point, but what if you want to create a confined user with different privileges?

I want to create a limited privilege terminal login user with the ability to send mail and read/write files in the /maildir directory.

My son Timothy uses his confined xguest account, but is not happy because he wants to communicate with his friends using AOL.

Fedora 9 has the solution. The SELinux management environment (system-config-selinux) has been updated and includes the ability to build customized SELinux policy modules for the confinement of users.

Remember, this tool is just a wizard–it helps create a framework for building policy. You can then use tools like audit2allow or the package eclipse-slide for further editing of the policy. Thiswill give you a good head start.

In the toolbar panel select:

System->Administration->SELinux Management

This starts system-config-selinux.

Select Policy Module and then Select the New button.

This will start the policy template generator (polgengui).

Click Forward.

As you can see, this screen has been enhanced to allow the creation of policy for confined users as well as confined applications. Writing policy for confined applications was described in a previous article.

The second column, Login Users, allows you to build policy modules that either customize existing user roles or create brand new roles. Selecting Existing User Roles allows you to build policy to change one of the default user types defined above. (guest, xguest, user, staff). Select one of the other radio buttons to define a new user role, based off of the 4 default user roles.

• Minimal Terminal User Role == guest_t
• Minimal X Windows User Role == xguest_t
• User Role == user_t
• Admin Role == staff_t

The final column, Root Users, allows you to define a user type that other user types can transition to when they are running as root. For example you could define a root role, dbadm, to administer the mysql database. You could set up the staff role to transition to this role using sudo.

I want to create a limited privilege terminal login user with the ability to send mail and read/write files in the /maildir directory?

In order to answer this question, we want to create a new Minimal Terminal User Role called mailuser.

Select Minimal Terminal User Role, and press Forward.

This screen displays a list of confined domains to which this role might transition. For example, if you wanted the mailuser to transition to the ethereal domain you would select this now. Since we do not want any transitions we will just hit forward.

This screen allows you to select other roles to which the current role can transition. This is where you would define the transition to dbadm from staff role described above. We will just hit Forward.

This screen allows you to select ports that the user can listen to. If the confined user was going to run a network server you could select the ports here. We will just select Forward.

Finally, we get to a screen which defines the ports the confined user can connect to. We will select the smtp port #25 and then go forward again.

This screen allows you to define a boolean. If you wanted to allow our confined user to connect to the mail port, only if the “allow_mailuser_sendmail” boolean is set, we could create the boolean here. We are not going to do this so select forward.

This screen allows us to select the directory to write the policy framework into. The directory must already exist.

This final screen tells you which files you are about to create. Press Apply.

The tool will create the following policy:

#vi /root/mailuser/mailuser.te
     policy_module(mailuser,1.0.0)
     ########################################
     #
     # Declarations
     #
     userdom_restricted_user_template(mailuser)

This one interface defines all the interaction of a guest user.

     #######################################
     #
     # mailuser local policy
     #
     sysnet_dns_name_resolve(mailuser_t)
     corenet_all_recvfrom_unlabeled(mailuser_t)
     allow mailuser_t self:tcp_socket create_stream_socket_perms;
     corenet_tcp_sendrecv_all_if(mailuser_t)
     corenet_tcp_sendrecv_all_nodes(mailuser_t)
     corenet_tcp_sendrecv_all_ports(mailuser_t)
     corenet_tcp_connect_smtp_port(mailuser_t)

These interfaces allow the mailuser_t to communicate with the smtp ports. Also, the policy generation tool added an interface to resolve host names. We now have enough policy to allow a mailuser_t to login to a machine and connect to a mail server, but not to read/write files to /maildir. This tool is just a framework-generating tool, not a policy editor. We will need to write policy for handing the /maildir directory ourselves. Since we want a directory that the mailuser can read/write to, we need to define a new type, mailuser_rw_t, then we need to tell the system that this is a type that affects files.

type mailuser_rw_t;
file_type(mailuser_rw_t)

We also need to allow mailuser_t to manage files and directories of this type:

manage_dirs_pattern(mailuser_t, mailuser_rw_t, mailuser_rw_t)
manage_files_pattern(mailuser_t, mailuser_rw_t, mailuser_rw_t)

We are done with the mailuser.te file.

Now, we want to define the file context in the mailuser.fc file:

# vi /root/mailuser/mailuser.fc

/var/maildir(/.*)?                  gen_context(system_u:object_r:mailuser_rw_t,s0)

We use regular expressions to define the path.

Now we can run the shell script to compile the policy and install it to the test system.

#  sh mailuser.sh
Building and Loading Policy
+ make -f /usr/share/selinux/devel/Makefile
Compiling targeted mailuser module
/usr/bin/checkmodule:  loading policy configuration from tmp/mailuser.tmp
/usr/bin/checkmodule:  policy configuration loaded
/usr/bin/checkmodule:  writing binary representation (version 8) to tmp/mailuser.mod
Creating targeted mailuser.pp policy package
rm tmp/mailuser.mod.fc tmp/mailuser.mod
+ /usr/sbin/semodule -i mailuser.pp
+ /usr/sbin/semanage user -a -R mailuser_r mailuser_u

At this point we have a new SELinx user mailuser_u installed on the machine. We want to assign a linux user to this type:

# semanage login -a -s mailuser_u dwalsh

We also want to create the directories /var/maildir:

# mkdir /var/maildir
# restorecon /var/maildir
# chown dwalsh:dwalsh /maildir

Now dwalsh can log in and use the /var/maildir directories.

But what about my son and his friends on AOL?

My son Timothy uses his confined xguest account, but is not happy because he wants to communicate with his friends using AOL.

I want to confine my son’s account so that only Firefox can talk to internet ports–but I want to allow his account to communicate with AIM/AOL. I can customize the xguest account and add this access.

Back at system-config-selinux I select New to create a new policy module.

I click forward through the intro screen to get to the policy module selection screen.

I want to modify an existing user role, so I click on Existing User Roles and then click forward.

The next box shows me the list of all exising user roles. Select xguest. The tool will add “my” to the policy name and create policy files named myxguest.

Click forward through the next couple of screens, until you reach the network connect screen.

Add the AOL Ports as a comma separated list, then click forward until the end.

Now take a look at the myxguest.te file that was created:

policy_module(myxguest,1.0.0) 

gen_require(`
      type xguest_t, xguest_devpts_t, xguest_tty_device_t;
      role xguest_r;
') 

########################################
#
# xguest customized policy
# 

sysnet_dns_name_resolve(xguest_t)
corenet_all_recvfrom_unlabeled(xguest_t) 

allow xguest_t self:tcp_socket create_stream_socket_perms;
corenet_tcp_sendrecv_all_if(xguest_t)
corenet_tcp_sendrecv_all_nodes(xguest_t)
corenet_tcp_sendrecv_all_ports(xguest_t)
corenet_tcp_connect_aol_port(xguest_t) 

allow xguest_t self:udp_socket { create_socket_perms listen };
corenet_udp_sendrecv_all_if(xguest_t)
corenet_udp_sendrecv_all_nodes(xguest_t)
corenet_udp_sendrecv_all_ports(xguest_t)

The tool added the AOL ports and the ability to resolve their hosts.

Compile to install the new policy like so:

sh myxguest.sh

Since I had previously set my son up to log in as xguest_u, no user management would need to be done. He can now use AOL Instant Messages in a secure environment.

If I had not set up his account I would need to execute:

# semodule login -a -s xguest_u twalsh

or

usermod -Z xguest_u twalsh

These examples show that it is fairly simple to extend SELinux confined users. If you need more advanced features, you can use system-config-selinux to build the framework and then use audit2allow or eclipse-slide to do further policy generation.

Next time, we will cover confinement of the root user.

To add to Fara’s post about the Dell.com redesign, I wanted to take the opportunity to explain how we design for the online user experience here at Dell and provide further insight into ways that Dell is continuing to foster a design-centric environment to benefit our customers.

Note: Click on any of the images in this post to see larger versions of all of them.

My team, an internal group of user experience designers, began our redesign efforts back in March with a lot of planning and strategy exploration. During this time we worked closely with internal business partners to define the objectives, requirements, and establish what success looked like to everyone. To build our strategy, we used current-state customer feedback and metrics as well as research and results from our previous design tests. This discovery process illustrated that there were a myriad of design options that we needed to consider.

Exploring these approaches took a lot of people, time and creative reviews. The initial round of designs included 24 different concepts and over 14 ways to navigate the page. After aligning on the goals for the page, our mission was clear: Beautiful imagery, more targeted navigation, space for fresh content, and more deep links into the site.

As we narrowed down the options, we tested the direction with users from our three main customer audiences (Consumer, Small & Medium Business, and Large Business) to ensure that we effectively captured each group’s needs. The feedback from this research informed some important design changes and reaffirmed the final design direction.

We know that a positive user experience has a direct correlation to a strong brand experience by allowing users to accomplish their goals easily. The end result of our efforts, which now live in the US with a 50% filter, accomplishes this with a clean and simple way to address the needs of our users by getting you where you want to go quicker.

Like Fara mentioned, we need your help to evolve the online experience at Dell.com. If you have thoughts to share about how to improve, respond to this post, go to the Dell Web Site area of IdeaStorm or weigh in at the Community Pulse page for Dell.com

如果宿舍里就你买了一瓶大宝，而且用了之后效果还挺不错。隔不久，你就发现最近这瓶大宝似乎用的有点快了，敢情是哪个哥们儿想买之前先试用一下？不巧的是，你恰好非常好奇这哥们儿是谁，想要搞一次秘密追踪。啥？指纹鉴别？噢，请原谅我没有那么专业的器材…… 不过土办法、馊主意我们还是有的：只要往大宝里掺和一点稀释过的辣椒水，隔天就等着找猴子屁股吧。^_+

扯太远了，其实本篇是想和大家分享一个在Linux下利用辣椒水的思路实现追踪程序被调用情况的小技巧。因为前段时间在分析Linux中各种内核模块被加载的方式、时间和源头。为此，我写了一个小小的Shell脚本：

trackme.sh

#!/usr/bash
echo [`date`] [`cat /proc/$PPID/cmdline | tr "\000" " "`] $0 $* > /var/log/$0.log
$0.org $*

然后将需要跟踪调用情况的程序更名（在我的例子中是/sbin下的modprobe和insmod），添加一个.org的后缀。再在原位置分别以原名（modprobe和insmod）创建符号链接指向上面这个脚本。

这样，一旦modprobe或insmod被执行，则案发时间、嫌疑人（包含完整的命令行）、作案手段（全部传入参数）均被完整记录在案（/var/log下同名的日志文件），一个都逃不掉！

最后补充一点，如果还需要记录在Linux启动早期initrd阶段中的调用，则需要将上述脚本打包到initrd镜像中，同时一并修改initrd中需要跟踪的程序（方法同上）。由于不同版本的Linux可能对/var/log处理方式有差别，最好将日志记录位置调整为/dev/shm（前提是内核中编译进了tmpfs模块）。这是一个相对安全的暂存空间，不会因为rootfs的更替而丢失，在启动完成后也可以顺利查阅到。

小小技巧，还望大虾们不要见笑，若能点拨一二，不甚感激！

嘿，小样，别以为抹了辣椒水我就认不出你了！

（接上一篇《唱片公司终于打中百度的七寸》、《百度的“千万广告大单”是“二桃杀三士”》）

相关新闻：近日，某商报报道，记者从一位业内知情人士处得知，百度正在全速加快其数字音乐战略部署——目前，一个为加入百度音乐联盟的唱片公司打造的新媒体平台正在秘密筹建，平台将全面服务唱片公司的音乐推广。

百度距离解决问题的方向越来越远

面对唱片公司的版权诉讼，百度接连使出公关手段，继千万广告大单给唱片公司分成新闻后，这次又祭出“推歌平台”的法宝。这些对策看似是百度的让步，但是实际上，百度离解决问题的目标越来越远。这个仅仅惠及少数唱片公司的利益的模式，其实还是延续了“二桃杀三士”的策略。

不知道谁想出来的这个“推歌平台”的主意。从表面上来看，“推歌平台”是一个帮助唱片公司推广歌曲的平台，实际上，却是一个滋生腐败的温床。这样一来，不仅断送了百度品牌，也让整个在线音乐市场陷入泥沼。

百度的模式是：百度要把自己变成一个媒体，而告别按搜索流量计数的公立平台。然后，百度把“新歌首发”等一些内部资源利用起来，专门给合作的唱片公司推广，只要唱片公司的歌曲上了百度TOP500排行榜，被点击的次数就越多，广告分成就越多。

这个模式让我们想起了运营商的彩铃业务：运营商控制着内部的推广资源，以及新歌首发等排行榜资源。然后SP和唱片公司们争相向运营商内部公关，拿到这些资源来获取利益。现在要在彩铃业务上赚钱，不是普通人想象中的创作并推广出一首好歌就可以了，真正赚钱的SP都是需要公关各省的彩铃业务负责人，来争取短信群发、捆绑等手段。如果没有这些非常规手段，是很难赚钱的。也是因为如此，导致无线音乐市场走向畸形。

现在，百度也从运营商那里学到了这个窍门，而设计了这一套模式。百度就把自己变成了运营商，然后跟运营商控制彩铃排行榜一样，百度利用TOP500的歌曲位置资源，并开放一些推广资源，按点击量给唱片公司广告分成，唱片公司得到推广资源越多、排名越靠前，分成就越多。这样，百度就可以一举两得。此模式不仅可以让百度少分钱给唱片行业；还可以让唱片公司服服帖帖的有求于自己，谁要是上榜或者得到更多分成，就必须得去贿赂百度的负责人。

“推歌平台”将滋生百度内部的腐败

我们知道，百度MP3最大的价值是它的排行榜，成了行业的风向标。但是成立了“推歌平台”以后，百度将逐步失去公正性，用户会更愿意去参考google趋势。百度的高端用户就会损失，而百度品牌价值降低，对音乐产业也并没有好处。因为没有社会责任感的大品牌会去投一个充满腐败的、充满黑幕的平台。消费者对百度失去了信任，流量减少，广告也会减少，唱片行业得到的分成也就会减少。最终是一个恶性循环，而收益的是少数腐败的人。

当然，百度方面可能说：我的TOP500肯定还会严格靠自然搜索量生成，即TOP500的规则是正规的，但是TOP500以外，百度可以为唱片公司提供不正规的推广手段，让歌曲进入TOP500。即便这样，也是滋生腐败的温床，这里面有太多的漏洞可钻。

从古鉴今，任何一个控制稀缺资源的制度、任何不透明的规则，都会滋生腐败。一个坏制度会把好人变坏，不完善的制度环境必定会腐蚀好同志。

根据无线音乐市场的前车之鉴，运营商音乐平台有太多的技术漏洞可钻，例如可以更改系统结算数据，而百度这么做更容易。另外运营商怕用户告状，而百度可以把广告分成任意分配，没有人监督。并且百度的这个模式，让唱片公司的收益跟歌曲本身没有直接关系，而变成个人因素来调动数据。

对于百度来说，只要控制新歌发行数量，人为掌控推广资源，其负责人的小利益集团就会更倾向于少干活，多受贿。因为一个一个的歌曲接入太烦琐了，于是，他们一定有理由说服上面，采取歌曲审核制，并更加严格限制的接入手段。以上还只是接入环节，在结算环节，因为数据是不透明的、随意的，所以会有很多财务漏洞和数据漏洞可以做手脚。并且在结算周期上，以及每一个环节上，都可以向唱片公司吃拿卡要。

这样，下只有少数聪明人、懂公关会贿赂的人能获得收益，而不是专心做好音乐、靠真本领的人获得收益。这种模式跟中彩票的模式一样，而不是公平地分给各个版权人，而是大多数人买单，少数人获益。

谁是百度“推歌平台”的最大受益者

首先不是唱片行业，在无线市场，唱片公司头上的爷是SP和运营商。百度的推歌平台一出，所有唱片公司多了一个爷。唱片公司在数字音乐市场上要彻底的求爷爷告奶奶了。

也不是百度公司。因为百度的公信度由此以来受到最大的损害。对于大品牌的广告商，谁会愿意给一个充满黑幕的网站投放广告？如果百度的广告收入不多，分给音乐产业的也就更少，会更加加剧双方的矛盾，引起更多的争议，这个“广告换版权”的模式就会告吹。

那么谁是百度“推歌平台”的最大收益者呢？当然是控制百度推广资源的权力人物。这个模式会逼使唱片公司来贿赂公关这些权力人物来选取推广资源。百度“推歌平台”最终形成少数人受益，大多数人受害的局面。

那么，谁是百度推广平台的最大受害者呢？当然是百度公司、唱片公司、音乐人、以及整个数字音乐产业链。可以想象，未来在线音乐市场成为一个怎么样市场：在线音乐市场严重萎缩，发展不起来。百度和唱片公司都去抢夺百度内部推广资源，而没有人去开拓百度以外的市场，百度平台变得封闭萎缩。

此“推歌平台”计划应该是在试验阶段，相信还没有大规模实施。所以请百度高层三思而后行。

爱之深，殷之切！希望百度理解音乐产业对百度的重大期望：百度是在线音乐市场的霸主，是最有机会变成惠及整个音乐产业的平台。能量越大，责任越大，希望百度能成为造福数字音乐产业的一员，而不是成为压迫数字音乐产业的一座大山。希望百度能学美国的开国总统华盛顿，可以立下一套让后世几百年受益的自由宪法，而不希望百度像股市一样制定混乱的规则，遗祸终生。最后，希望百度让唱片公司多一个宣传歌曲的人员配置，把资源更多用来推广市场上，而不是多出一个用来贿赂百度的人员配置。

给百度的建议：

1、解决方案应该是开放平台，广泛联盟。首先百度需要联合其他媒体推广渠道，整合把自己内部的贴吧、空间、掌门人等，并整合电视台的颁奖节目，把百度的平台影响力做到最大。例如中移动就联合东方卫视举办无线颁奖典礼，扩大市场影响。但是百度需要正版化，否则周杰伦等知名艺人也不会参加颁奖节目。

作为在线音乐行业的霸主，需要有社会责任感，一个真正有诚意的做法应该是：百度面对所有唱片公司，做出一个让所有版权人都可以受惠的解决方案。希望百度做平台，而不是搞控制，现在这个让少数人收益的制度，必定导致腐败，并限制百度平台的发展。百度需要制定一个政策，可以和音乐产业一直对外做大蛋糕，而不是争夺内部资源。

2、公开数据，建立一个透明完善的规则

在我的文章《远离彩票、远离股票、远离版权》中提到，没有一个透明的机制，唱片公司在里面得不到收益。经济学家郎咸平也经常批评中国股市有一个完善的规则，让股市变得跟赌场一样。既然是赌场，十赌九骗老话就非常灵验，果然，中国股市是一个庄家操纵的烂摊子。同样，没有一个严格、透明的规则，百度音乐平台也将变成一个腐烂赌场。

现在，音乐产业比大家想象中要糟糕10倍。对于面临崩溃的音乐产业来说，演出市场已经受奥运和灾难影响，而无线市场也已经走向畸形。现在，如果在线市场不尽快推出好的规则，那么唱片公司真的就要关门。覆巢之下,焉有完卵。可能每一个音乐人都再也坐不住了。

我们总在说优化，有这么多可优化的地方吗？
开发需求：

看起来好像很简单，没什么不对的地方。
仔细分析业务，我发现content_id,update_date是唯一的，如果我们把这两个字段做个联合主键，那岂不是可以省略id主键，节省空间。表结构修改为：

这样下来，表记录少一个字段id，少一个id索引，每行记录节省了十几个字节，对于很小的表空间省略是微不足道的，但是对于上千万行记录的表来说，节省的空间还是相当可观的。

很多微不足道的地方，优化起来也是有用的，能省则省嘛。

dbanotes posted a photo:

最近在思考一些 SOA 与 DB 之间的关系 （没错，这东西很虚）。这张图来自 Ibm 的红皮书。

dbanotes posted a photo:

最近在思考一些 SOA 与 DB 之间的关系 （没错，这东西很虚）。这张图来自 Ibm 的红皮书。

Shared by Fenng
Dtrace 如果能弄到 Linux 上，以后优化就方便多了

The interest in DTrace on Linux is heating up again -- this time in an inferno on the Linux 2008 Kernel Summit discussion list. Under discussion is SystemTap, the Linux-born DTrace-knockoff, with people like Ted Ts'o explaining why they find SystemTap generally unusable ("Do you really expect system administrators to use this tool?") and in stark contrast to DTrace ("it just works").

While the comparison is clearly flattering, I find it a bit disappointing that no one in the discussion seems to realize that DTrace "just works" not merely my implementation, but also by design. Over and over again, we made architectural and technical design decisions that would yield an instrumentation framework that would be not just safe, powerful and flexible, but also usable. The subtle bit here is that many of those decisions were not at the surface of the system (where the discussion on the Linux list seems to be currently mired), but in its guts. To phrase it more concretely, innovations like CTF, DOF and provider-specified stability may seem like mind-numbing, arcane implementation detail (and okay, they probably are that too), but they are the foundation upon which the usability of DTrace is built. If you don't solve the problems that they solve, you won't have a system anywhere near as usable as DTrace.

So does SystemTap appreciate either the importance of these problems or the scope of their solutions? Almost certainly not -- for if they did, they would come to the same conclusion that technologists at Apple, QNX, and the FreeBSD project have come to: the only way to have a system at parity with DTrace is to port DTrace.

Fortunately for Linux users, there are some in the community who have made this realization. In particular, Paul Fox has a nascent port of DTrace to Linux. Paul still has a long way to go (and I'm sure he could use whatever help Linux folks are willing to offer) but it's impossible to believe that Paul isn't on a shorter and more realistic path than SystemTap to achieving safe, powerful, flexible -- and usable! -- dynamic Linux instrumentation. Good luck to you Paul; we continue to be available to help where we can -- and may the Linux community realize the value of your work sooner rather than later!