相信不少朋友, 對"唔怕一萬, 至怕萬一"這說話有一定認識... 究竟, 你跟我的認識有何不同呢??
從數學角度看, "唔怕一萬, 至怕萬一"是指一件事件發生的概率 (Probability). 對! 就是 Probability.
Prob(事件發生) = 1/10001
即是說, 事件發生的可能性為: 每10001個機會, 發生1次
所以... 唔怕一萬, 至怕萬一發生事情!
現在, 由另一個角度看吧~
一萬是 10000, 萬一是 10001
讀電腦的 ... 你會如何理解 10000 及 10001?
無錯! 二進制!
10000 = 16
10001 = 17
16 即 實碌
17 即 實柒
碌乃為幸運之意, 柒乃為真係柒之意
唔怕一萬, 至怕萬一 .... 即是說一件事情, 唔怕走運, 至怕"柒ed"
夠爛嗎? XDDDDDDDDDDDDDDDD
Friday, September 18, 2009
貼紙... 我的第一次
因為要準備 Sept 19 的 Software Freedom Day, 這數天, 除了花時間到自己要做的事, 很多時間花了在 SFD 上.
這一兩天, 就是花在小弟第一次整的貼紙上. 雖然那些貼紙, 未有想像中的好... (size 細了) 但還是要做吧 XD
我的工作間, 已被貼紙攻佔!!
而我工作就係... 張 1x6 的大大貼紙群, 修剪為 1x1 的小小貼紙仔 (即下圖)
其中... 最喜歡的一 set 貼紙, 當然是 ... Linux Kernel in the Black Box =]
近呢幾日都會寫 ... "You make SFD Happen!"
想知 SFD 會點? Sept 19 到城大逛逛 =] http://bit.ly/registersfd09hk
p.s. 其實我好整齊架 ._.
這一兩天, 就是花在小弟第一次整的貼紙上. 雖然那些貼紙, 未有想像中的好... (size 細了) 但還是要做吧 XD
我的工作間, 已被貼紙攻佔!!
而我工作就係... 張 1x6 的大大貼紙群, 修剪為 1x1 的小小貼紙仔 (即下圖)
 |  |
其中... 最喜歡的一 set 貼紙, 當然是 ... Linux Kernel in the Black Box =]
近呢幾日都會寫 ... "You make SFD Happen!"
想知 SFD 會點? Sept 19 到城大逛逛 =] http://bit.ly/registersfd09hk
p.s. 其實我好整齊架 ._.
Friday, September 11, 2009
o... i just passed
=P I passed the qual-round ~~~ And, will die in upcoming round 1-a,1-b, and 1-c XDDDDDDDD
Sunday, September 06, 2009
Enabling MLS policy module in SELinux
This "experiment" is carried on late of August, 2009.
Environment: Fedora Core 11 (guest) under VirtualBox-3.0.4 on Ubuntu-9.0.4 (host)
MLS Policy Module Version: 3.6.12
Credits: Most information about SELinux comes from Red Hat Enterprise Linux 5 Deployment Guide [ref-G] and MLS setup procedures come from Fedora Project Wiki. And, Getting Started with SE Linux HOWTO gives me better understanding. If you like reading SELinux from academic paper, consult A logical specification and analysis for SELinux MLS policy.
SELinux Overview in Brief
---
In standard Linux Distro, there is Discretionary Access Control (DAC). Any process running as a user has the permission to any object (file, socket, executable...) as the user. A typical ls -l shows the permission of objects.
For example, the object "Mario_Gant" is owned by user and grouped under the group "user". The permission of the object is rwx:r-x:r-x for owner:group:others respectively. The owner - "user" is granted to read-write-execute of the object. The group - "user" is granted to read-execute. And, any person other than the owner or outside the group of "user" have the read-execute permission on the object. This is typical DAC on any Linux Distro.
SELinux builds another access control layer on top of DAC - the Mandatory Access Control (MAC). SELinux privilege checking is first carried on DAC and then MAC. If DAC denied the access, MAC is not carried. SELinux Decision Process is visualized in [ref-G] as shown below.
Any subject passed DAC checking fires an action request on an object to the SELinux Security Server, a.k.a. the policy enforcement server. The server consult the SELinux Policy Database, either from the Access Vector Cache (AVC) or security context matrix on disk, for policy on that particular object requested. The server grants permission to the subject according to policy consulted. If permission is denied, a denial message is logged.
There are 2 modes of operation in SELinux - Enforcing mode and Permissive mode. The only difference between 2 modes is that Permissive mode does not deny any unprivileged MAC attempt but those unprivileged attempts will be logged. Permissive mode is useful for troubleshooting and development of security contexts.
Security Contexts, User, Role, Type/Domain
SELinux security context of any object is stored as file attribute. Context of object can be viewed by issuing ls -Z. A typical context is shown below.
user_u:object_r:tmp_t:Moonbase_Plans refers to {SELinux User}:{SELinux Role}:{SELinux Domain/Type}:{SELinux MCS/MLS Label} respectively.
Here, SELinux User is different to user in conventional Linux. For instance, a linux user 'pi' is configured as SELinux user "user_u". If 'pi' issue su command to login as 'root', he/she's SELinux user identity is still 'user_u' and thus security policies applied on 'user_u' still remains. Mapping between SELinux User and typical linux uid is maintained by SELinux Login. SELinux Login can be viewed by issuing semanage login -l
The first column is typical linux uid while second column is the SELinux user identity. The last column is the MLS/MCS (Multi Level Security/Multi Category System) Range. MLS and MCS is two different security policies. MLS will be explained in later section in this article.
In above example, different linux uids are mapped to two SELinux User. To obtain the definition of those SELinux User, issue semanage user -l
In this snap, SELinux User 'root' is having 3 different SELinux Roles while it's the same as 'user_u'. However, 'user_u' is being mapped to all typical linux uid while 'root' is mapped to uid 'root' as system administrator. The user, 'system_u', is dedicated for system processes.
Let's move on to SELinux Roles. It is part of SELinux Role-based Access Control and predefined in SELinux policies. SELinux Role determines which process domains / object types can be accessed. All processes under SELinux run under a domain. A domain specifies what can be performed by processes while a type specifies who can access an object.
Roles are predefined. For instance, 'system_r' is the role specifically for all system processes except user processes. It allows domains/types like .. dhcpd_t, httpd_t, initrc_t, and ldconfig_t. These domains/types are for dhcp daemon, http daemon, initrc script, and ldconfig respectively.
SELinux actually is not that complicated ... Let's keep it short! When you login, you obtain a role. This role can perform certain tasks according to predefined rules. Those rules make use of domain and type. So, if your role does not match the specified domain / type, permission deny as result. A SELinux user can have more than a single role. Thus, user may switch between role for certain tasks.
MLS Policy
---
MLS policy in SELinux is implemented like an add-on to SELinux MAC. MLS is abbreviation of Multi-Level Security. So, what is multi-level? It is actually derived from Bell-La Padula model.
In short, using the military terms, a general that can view national secret stuffs can also view national confidential stuffs and of course unclassified stuffs. But, general does not have enough privileges to view stuffs that are classified as national top secret like ... UFO ^^? On the other hand, a general would report to the upstreams but not report anything to the soldiers. (Like you have to report to your boss all the time @@?) This is the general belief behind Bell-La Padula model - "no read up, no write down".
To put this concept into SELinux, look at the self-explanatory visualization from [ref-G].
MLS further extends BLP by allowing categorization, a.k.a. compartment. For example, if UFO is considered as top secret, it belongs to the UFO category. At the same time, another top secret category would be Nuclear. Someone that is allowed to access top secret information related to UFO does not necessarily need to access information about Nuclear. You may consider as sub-levels.
SELinux implementation provides 16 default levels - from s0 (lowest) to s15 (highest), and 1024 categories - from c0 to c1023. Level can be added on demand by editing the file '/etc/selinux/mls/setrans.conf'. At the same time, MLS policy has its own set of roles definition. According to Fedora wiki, roles include: user_r, staff_r, sysadm_r, secadm_r, and auditadm_r. Other than that, DAC, SELinux Role, Type, and Domain still applies with MLS policy.
The Experiment - setup
---
Steps listed below are used to carry my experiment in enabling MLS policy in SELinux under FC11.
1. Installing FC11 with the wonderful LiveCD.
2. Update your fresh installation in order to fix anything the update can fix
To update in FC11, Do the following as root.
*Note: I do this in my tea time ... as the update took me around 30minutes to complete.
3. Install and configure the MLS policy
Again, do as root.
Then, vi the file '/etc/selinux/config' to configure SELinux. Setting the two config-variable as follows.
This configuration tells SELinux to operate in permissive mode (the one mentioned in previous section that it just warns) and use the MLS policy.
4. Ask SELinux to relabel with MLS policy
Issue "touch /.autorelabel" in your terminal so that your next boot will ask SELinux to relabel stuffs with the MLS policy. Then, reboot into single-user mode (see friendly reminder [2] in order to know howto do so) and the relabeling will start. Once relabeling is finished, issue "init 3" to boot into run-level 3.
5. Enabling MLS policy and Getting Back the GUI
To turn on MLS policy, edit the file '/etc/selinux/config' and set 'SELINUX=enforcing'
To turn off MLS policy, edit the file '/etc/selinux/config' and set 'SELINUX=permissive'
To turn on GUI, edit the file '/etc/inittab' and set 'id:5:initdefault:'
To turn off GUI, edit the file '/etc/inittab' and set 'id:3:initdefault:'
The Experiment - tryout
---
In this trial, we are going to setup 2 files with different MLS level, 2 SELinux User with different MLS level, and to see if MLS policies apply correctly.
*Note: Carry the following as root and SELinux in permissive mode. semanage may not work fine in enforcing mode.
1. Creating users and specifies MLS levels for user
In case, Alice is assigned to SELinux user s1_u while Bob is assigned to s2_u. And, they are having different MLS levels. You need to set password for Alice and Bob by issuing passwd.
2. Creating files and apply security context to them
As SELinux policy first check DAC, chmod 777 allows the checking to be passed. Then set the security context to /file1 and /file2 respectively. /file1 belongs to MLS level s1 while /file2 belongs to MLS level s2. The last step is to restore the new context by issuing restorecon.
3. See what happen
First, switch SELinux into enforcing mode by issuing "echo 1 > /selinux/enforce". Do the following and see what happen.
(a) You're still login as root, try to cat /file1 and cat /file2. You probably get permission denied. You may issue ls -Z / and you may find "strange" thing like...
Even root is the owner of /file1 and /file2, root cannot access the files. This is because, by default, root is having MLS level s0 when login. By definition that can be viewed by semanage login -l, root can access levels from s0 to s15. To switch your MLS level to s15, issue newrole -l s15. Now, you can cat /file1 and /file2.
(b) Login as Alice, try to cat /file1 and cat /file2. You probably get content in /file1 but not in /file2. The reason is simple, user with MLS level s1 can access s1 objects but not objects in level s2. By Bell-La Padula model, you cannot read up ^^.
(c) Login as Bob, try to cat /file1 and cat /file2. You probably get content in both /file1 and /file2. By definition of Bell-La Padula model again, you can read down ^^.
(d) Try to write any stuff into /file1 or /file2 with any MLS level. You probably find that you get permission denied. The reason? SELinux MLS policy module is still "experimental" in FC11.
Environment: Fedora Core 11 (guest) under VirtualBox-3.0.4 on Ubuntu-9.0.4 (host)
MLS Policy Module Version: 3.6.12
Credits: Most information about SELinux comes from Red Hat Enterprise Linux 5 Deployment Guide [ref-G] and MLS setup procedures come from Fedora Project Wiki. And, Getting Started with SE Linux HOWTO gives me better understanding. If you like reading SELinux from academic paper, consult A logical specification and analysis for SELinux MLS policy.
SELinux Overview in Brief
---
Security-Enhanced Linux (SELinux) is a security architecture integrated into the 2.6.x kernel using the Linux Security Modules (LSM). It is a project of the United States National Security Agency (NSA) and the SELinux community. SELinux integration into Red Hat Enterprise Linux was a joint effort between the NSA and Red Hat.
-- 44.2. Introduction to SELinux, [ref-G]
In standard Linux Distro, there is Discretionary Access Control (DAC). Any process running as a user has the permission to any object (file, socket, executable...) as the user. A typical ls -l shows the permission of objects.
For example, the object "Mario_Gant" is owned by user and grouped under the group "user". The permission of the object is rwx:r-x:r-x for owner:group:others respectively. The owner - "user" is granted to read-write-execute of the object. The group - "user" is granted to read-execute. And, any person other than the owner or outside the group of "user" have the read-execute permission on the object. This is typical DAC on any Linux Distro.
SELinux builds another access control layer on top of DAC - the Mandatory Access Control (MAC). SELinux privilege checking is first carried on DAC and then MAC. If DAC denied the access, MAC is not carried. SELinux Decision Process is visualized in [ref-G] as shown below.
Any subject passed DAC checking fires an action request on an object to the SELinux Security Server, a.k.a. the policy enforcement server. The server consult the SELinux Policy Database, either from the Access Vector Cache (AVC) or security context matrix on disk, for policy on that particular object requested. The server grants permission to the subject according to policy consulted. If permission is denied, a denial message is logged.
There are 2 modes of operation in SELinux - Enforcing mode and Permissive mode. The only difference between 2 modes is that Permissive mode does not deny any unprivileged MAC attempt but those unprivileged attempts will be logged. Permissive mode is useful for troubleshooting and development of security contexts.
Security Contexts, User, Role, Type/Domain
SELinux security context of any object is stored as file attribute. Context of object can be viewed by issuing ls -Z. A typical context is shown below.
[root@myServer ~]# ls -Z gravityControl.txt
-rw-r--r-- user user user_u:object_r:tmp_t:Moonbase_Plans gravityControl.txt
user_u:object_r:tmp_t:Moonbase_Plans refers to {SELinux User}:{SELinux Role}:{SELinux Domain/Type}:{SELinux MCS/MLS Label} respectively.
Here, SELinux User is different to user in conventional Linux. For instance, a linux user 'pi' is configured as SELinux user "user_u". If 'pi' issue su command to login as 'root', he/she's SELinux user identity is still 'user_u' and thus security policies applied on 'user_u' still remains. Mapping between SELinux User and typical linux uid is maintained by SELinux Login. SELinux Login can be viewed by issuing semanage login -l
[root@dhcp-133 ~]# semanage login -l
Login Name SELinux User MLS/MCS Range
__default__ user_u s0
james user_u s0
daniel user_u s0
root root s0-s0:c0.c1023
olga user_u s0
The first column is typical linux uid while second column is the SELinux user identity. The last column is the MLS/MCS (Multi Level Security/Multi Category System) Range. MLS and MCS is two different security policies. MLS will be explained in later section in this article.
In above example, different linux uids are mapped to two SELinux User. To obtain the definition of those SELinux User, issue semanage user -l
[root@dhcp-133 ~]# semanage user -l
Labeling MLS/ MLS/
SELinux User Prefix MCS Level MCS Range SELinux Roles
root user s0 s0-s0:c0.c1023 system_r sysadm_r user_r
system_u user s0 s0-s0:c0.c1023 system_r
user_u user s0 s0-s0:c0.c1023 system_r sysadm_r user_r
In this snap, SELinux User 'root' is having 3 different SELinux Roles while it's the same as 'user_u'. However, 'user_u' is being mapped to all typical linux uid while 'root' is mapped to uid 'root' as system administrator. The user, 'system_u', is dedicated for system processes.
Let's move on to SELinux Roles. It is part of SELinux Role-based Access Control and predefined in SELinux policies. SELinux Role determines which process domains / object types can be accessed. All processes under SELinux run under a domain. A domain specifies what can be performed by processes while a type specifies who can access an object.
Roles are predefined. For instance, 'system_r' is the role specifically for all system processes except user processes. It allows domains/types like .. dhcpd_t, httpd_t, initrc_t, and ldconfig_t. These domains/types are for dhcp daemon, http daemon, initrc script, and ldconfig respectively.
SELinux actually is not that complicated ... Let's keep it short! When you login, you obtain a role. This role can perform certain tasks according to predefined rules. Those rules make use of domain and type. So, if your role does not match the specified domain / type, permission deny as result. A SELinux user can have more than a single role. Thus, user may switch between role for certain tasks.
MLS Policy
---
MLS policy in SELinux is implemented like an add-on to SELinux MAC. MLS is abbreviation of Multi-Level Security. So, what is multi-level? It is actually derived from Bell-La Padula model.
The term multi-level arises from the defense community's security classifications: Confidential, Secret, and Top Secret. -- 44.6.1 Why Multi-Level, [ref-G]
In short, using the military terms, a general that can view national secret stuffs can also view national confidential stuffs and of course unclassified stuffs. But, general does not have enough privileges to view stuffs that are classified as national top secret like ... UFO ^^? On the other hand, a general would report to the upstreams but not report anything to the soldiers. (Like you have to report to your boss all the time @@?) This is the general belief behind Bell-La Padula model - "no read up, no write down".
To put this concept into SELinux, look at the self-explanatory visualization from [ref-G].
MLS further extends BLP by allowing categorization, a.k.a. compartment. For example, if UFO is considered as top secret, it belongs to the UFO category. At the same time, another top secret category would be Nuclear. Someone that is allowed to access top secret information related to UFO does not necessarily need to access information about Nuclear. You may consider as sub-levels.
SELinux implementation provides 16 default levels - from s0 (lowest) to s15 (highest), and 1024 categories - from c0 to c1023. Level can be added on demand by editing the file '/etc/selinux/mls/setrans.conf'. At the same time, MLS policy has its own set of roles definition. According to Fedora wiki, roles include: user_r, staff_r, sysadm_r, secadm_r, and auditadm_r. Other than that, DAC, SELinux Role, Type, and Domain still applies with MLS policy.
The Experiment - setup
---
Steps listed below are used to carry my experiment in enabling MLS policy in SELinux under FC11.
1. Installing FC11 with the wonderful LiveCD.
2. Update your fresh installation in order to fix anything the update can fix
To update in FC11, Do the following as root.
yum update
reboot
*Note: I do this in my tea time ... as the update took me around 30minutes to complete.
3. Install and configure the MLS policy
Again, do as root.
yum install selinux-policy-mls
Then, vi the file '/etc/selinux/config' to configure SELinux. Setting the two config-variable as follows.
SELINUX=permissive
SELINUXTYPE=mls
This configuration tells SELinux to operate in permissive mode (the one mentioned in previous section that it just warns) and use the MLS policy.
4. Ask SELinux to relabel with MLS policy
Issue "touch /.autorelabel" in your terminal so that your next boot will ask SELinux to relabel stuffs with the MLS policy. Then, reboot into single-user mode (see friendly reminder [2] in order to know howto do so) and the relabeling will start. Once relabeling is finished, issue "init 3" to boot into run-level 3.
5. Enabling MLS policy and Getting Back the GUI
To turn on MLS policy, edit the file '/etc/selinux/config' and set 'SELINUX=enforcing'
To turn off MLS policy, edit the file '/etc/selinux/config' and set 'SELINUX=permissive'
To turn on GUI, edit the file '/etc/inittab' and set 'id:5:initdefault:'
To turn off GUI, edit the file '/etc/inittab' and set 'id:3:initdefault:'
The Experiment - tryout
---
In this trial, we are going to setup 2 files with different MLS level, 2 SELinux User with different MLS level, and to see if MLS policies apply correctly.
*Note: Carry the following as root and SELinux in permissive mode. semanage may not work fine in enforcing mode.
1. Creating users and specifies MLS levels for user
adduser alice
adduser bob
semanage user -a -L s1 -r s1:c0.c1023 -R user_r -P user s1_u
semanage user -a -L s2 -r s2:c0.c1023 -R user_r -P user s2_u
semanage login -a -s s1_u -r s1:c0.c1023 alice
semanage login -a -s s2_u -r s2:c0.c1023 bob
In case, Alice is assigned to SELinux user s1_u while Bob is assigned to s2_u. And, they are having different MLS levels. You need to set password for Alice and Bob by issuing passwd.
2. Creating files and apply security context to them
echo "This is file 1" > /file1
echo "This is file 2" > /file2
chmod 777 /file1
chmod 777 /file2
semanage fcontext -a -r s1 -s s1_u -t user_t /file1
semanage fcontext -a -r s2 -s s2_u -t user_t /file2
restorecon -v /file1
restorecon -v /file2
As SELinux policy first check DAC, chmod 777 allows the checking to be passed. Then set the security context to /file1 and /file2 respectively. /file1 belongs to MLS level s1 while /file2 belongs to MLS level s2. The last step is to restore the new context by issuing restorecon.
3. See what happen
First, switch SELinux into enforcing mode by issuing "echo 1 > /selinux/enforce". Do the following and see what happen.
(a) You're still login as root, try to cat /file1 and cat /file2. You probably get permission denied. You may issue ls -Z / and you may find "strange" thing like...
?--------- ? ? file1
?--------- ? ? file2
Even root is the owner of /file1 and /file2, root cannot access the files. This is because, by default, root is having MLS level s0 when login. By definition that can be viewed by semanage login -l, root can access levels from s0 to s15. To switch your MLS level to s15, issue newrole -l s15. Now, you can cat /file1 and /file2.
(b) Login as Alice, try to cat /file1 and cat /file2. You probably get content in /file1 but not in /file2. The reason is simple, user with MLS level s1 can access s1 objects but not objects in level s2. By Bell-La Padula model, you cannot read up ^^.
(c) Login as Bob, try to cat /file1 and cat /file2. You probably get content in both /file1 and /file2. By definition of Bell-La Padula model again, you can read down ^^.
(d) Try to write any stuff into /file1 or /file2 with any MLS level. You probably find that you get permission denied. The reason? SELinux MLS policy module is still "experimental" in FC11.
Thursday, September 03, 2009
CodeJam 2009, Did you ^^?
Haha ~~ codejam is back:p
This morning ... i was struggling with the problem set :p
And... finally tackled the easiest one :p
BUT .... if you carry the codejam early in the morning ... you will find if you download the input data... You get THIS XD
And ... you can check the QA list for the error...
This morning ... i was struggling with the problem set :p
And... finally tackled the easiest one :p
BUT .... if you carry the codejam early in the morning ... you will find if you download the input data... You get THIS XD
And ... you can check the QA list for the error...
