On Fri, 23 Sep 2011, Craig Sanders <cas(a)taz.net.au> wrote:
> On Thu, Sep 22, 2011 at 08:52:35PM -0700, Daniel Pittman wrote:
> > So, the biggest advantage is that it does work against all those
> > attacks that compromise the kernel and/or drivers to get into the
> > kernel after a restart. Which, indeed, is where many of the "root
> > kit" tools hit, on Windows.
>
> so the "solution" is to prevent installation of competing operating
> systems that don't have the security flaws that allow malware to
> compromise the kernel? or the BIOS.
>
> wonderful. makes perfect sense.
If you ran a corporate IT department and had a set of Linux laptops then it
would be handy to be able to lock them down to prevent them from being used
for gaming, pr0n, etc. A BIOS that could be locked to a GPG key to only load
a signed kernel and initrd could be a first stage towards a locked down
system.
Like many technologies this can be used for good or evil.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On Tue, 20 Sep 2011, Andrew Spiers <7andrew(a)gmail.com> wrote:
> Is there a semanage command to set which users can access this file? I
> can't figure it out from the man page.
You don't "set which users can access a file". You set the context of the
file which then determines (according to the policy database) whether a
process of a given context is permitted to access it.
http://doc.coker.com.au/computers/se-linux-terminology/
The context of a process for the user shell is determined by the SE Linux
"identity" assigned to their account and the "role" assigned to that identity.
See the above URL for some background.
On Tue, 20 Sep 2011, Andrew Spiers <7andrew(a)gmail.com> wrote:
> and yet restorecon does not change unconfined_u to system_u.
Try with the -F option.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
On Thu, Sep 22, 2011 at 08:52:35PM -0700, Daniel Pittman wrote:
> So, the biggest advantage is that it does work against all those
> attacks that compromise the kernel and/or drivers to get into the
> kernel after a restart. Which, indeed, is where many of the "root
> kit" tools hit, on Windows.
so the "solution" is to prevent installation of competing operating
systems that don't have the security flaws that allow malware to
compromise the kernel? or the BIOS.
wonderful. makes perfect sense.
craig
--
craig sanders <cas(a)taz.net.au>
BOFH excuse #145:
Flat tire on station wagon with tapes. ("Never underestimate the bandwidth of a station wagon full of tapes hurling down the highway" Andrew S. Tannenbaum)
OSIA-OSDC MiniConference: The Business of Open Source.
OSIA is pleased to announce its forthcoming first one day OSIA-OSDC
Mini-Conference, 14 November 2011, Canberra.
For more details please visit http://osia.com.au/events
You will find the Call for Papers - also posted below and other details
will be posted as they become available at the above website address. To
note closing date for submission is 7 October 2011.
The Business of Open Source Solutions
OSIA – OSDC Mini-Conference
Call for Papers
OSIA is pleased to announce that it is accepting papers for the first
one day OSIA-OSDC Mini-Conference on 14 November, 2011. This event will
be held in the leadup to the main OSDC Conference at ANU, in Canberra,
Australia. The Call for Papers is open until Friday 7 October 2011,
after which time submissions will be reviewed and successful presenters
will be notified. Presenters may be invited to the Mini-Conference.
Papers from all aspects of Open Source are welcome, but preference may
be given to those with a Business or Business Development slant.
Aims of the Mini-Conference
This Mini-Conference will attempt to:
1. raise awareness of successful business models for FOSS;
2. demonstrate through case studies the commercial viability of FOSS
3. reiterate the benefits to businesses of deploying FOSS
4. summarize the current FOSS acquisition policies of Commonwealth and
State governments
The event will be of primary interest to developers and business people
seeking to market FOSS solutions to industry and government, but will
also be of interest to entities considering deployment of FOSS solutions
in their enterprises.
Presentation Format
Presentation will be one of:
1. 30 mins Short talk
2. 1 hr Presentation, possibly of a Tutorial nature or with a longer Q&A
session.
3. 1 hr Interactive Forum / Panel Discussion session.
*Proposal for an Interactive Forum session will be highly regarded.*
Submission
Please provide an abstract of your presentation, including your name, a
brief bio of presenter(s), affiliation and contact details, and indicate
which type of presentation (30mins Short or 1hr Long) you are submitting
for.
Email to : osia-events(a)osia.com.au
by the close of submission (7 October, 2011).
Please note that all those presenting at the OSIA-OSDC Mini-Conference
who is NOT also attending the main OSCD conference will be waived the
entry fee to the Mini-Conference.
The entry fee for Delegates not attending the main OSDC Conference is $50.00
OSIA looks forward to receiving your proposal soon.
For further information as they become available please visit:
www.osia.com.au/events
Daniel Jitnah
OSIA Director – Events.
--
----------------------------------------
Daniel Jitnah
Melbourne, Australia
e: djitnah(a)greenwareit.com.au
w: www.greenwareit.com.au
SIP: dj-git(a)ekiga.net
----------------------------------------
** For All your Linux, Open Source and IT requirements visit: www.greenwareit.com.au **
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
For All your Open Source and IT requirements see: www.greenwareit.com.au
Daniel Pittman <daniel(a)rimspace.net> wrote:
> There was recently announced a root-kit that would infest Award BIOS
> implementations:
> http://www.symantec.com/security_response/writeup.jsp?docid=2011-090609-455…
>
> So, fairly high risk for the next little while, until vendors do
> something to harden against firmware updates?
Short of disallowing them at all, or requiring signed firmware, it isn't clear
what could be done. Obviously, the attacker needs a local root exploit (or
whatever the Microsoft equivalent is) in order to modify the firmware, but I
agree that having a root kit in the firmware would be a very bad position to
occupy.
> So, the biggest advantage is that it does work against all those
> attacks that compromise the kernel and/or drivers to get into the
> kernel after a restart. Which, indeed, is where many of the "root
> kit" tools hit, on Windows.
That's interesting... and the proposed solution just happens to be the one
which also has potential to disadvantage competitors...
Daniel Pittman <daniel(a)rimspace.net> wrote:
> More so, even, if Microsoft are not responsible for the restriction –
> if they specify that their key, or the OEM key, need to be present to
> run Windows, but do not restrict other keys being included.
>
> ...and I suspect that the vendors, also, will not be on the hook here:
> there are plenty of other hardware vendors, and their choice not to
> support Linux will not be substantially different to their choice not
> to support ARM operating systems: a business decision, allowing their
> competition to "take" that market share.
I'd be worried if most vendors were to take that option, however. In general,
consumer systems are becoming increasingly locked-down (phones, tablets, now
laptops and desktops too). Obviously, the freedom to run whatever kernel you
want, including one compiled by you, is fundamental to Linux usage and
development, hence it is vital to protect.
>
> Personally, I would be finding a tame SuperMicro vendor in the region,
> who are extremely unlikely to stop selling Linux compatible systems,
> what with their business market using it and all.
We do need vendors who are committed to Linux, in addition to pursuing
whatever can be gained through competition law.
To play my part, I always choose hardware whenever I can for which the vendor
claims Linux support (after doing the proper checking to ensure that it really
is likely to work reliably). For example, my desktop machine is a workstation
product certified to run Red Hat. I'm actually running Debian on it, but at
least it is hardware that could be bought with Linux pre-installed.
I think the people who are more likely to be affected by Microsoft's strategy,
in the short term, are those running Windows who want to switch to Linux
on their existing hardware, as well as Linux users who buy Windows machines
for the purpose of installing Linux. Laptops would be particularly
problematic.
[Apologies to those who've got multiple copies of this]
This looks like something to keep an eye on.. Matthew
Garrett (the guy who makes peoples laptops work with Linux
and has to deal with EFI & Linux - makes you wonder what
awful thing he did in a past life) writes about a worrying
requirement for Windows 8 logo certification for hardware
vendors..
http://mjg59.dreamwidth.org/5552.html
# Microsoft requires that machines conforming to the
# Windows 8 logo program and running a client version
# of Windows 8 ship with secure boot enabled. The two
# alternatives here are for Windows to be signed with
# a Microsoft key and for the public part of that key
# to be included with all systems, or alternatively for
# each OEM to include their own key and sign the
# pre-installed versions of Windows. The second approach
# would make it impossible to run boxed copies of Windows
# on Windows logo hardware, and also impossible to install
# new versions of Windows unless your OEM provided a new
# signed copy. The former seems more likely.
#
# A system that ships with only OEM and Microsoft keys will
# not boot a generic copy of Linux.
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
I have a USB-serial cable connecting my laptop (running 2.6.39 from
Debian) to a weather station.
My keyboard is connected to a different USB port on the laptop. Whenever
the met software is reading and/or writing to the serial port (I haven't
yet debugged whether it only happens during read or write), the keyboard
badly lags when in X, but not at the console. I don't *think* the mouse
is affected, most of the time, unless X is waiting for the keyboard to
catch up.
I'm apparently using the evdev driver. In xorg.conf, synaptics is
configured for the mouse, talking on /dev/psaux, and not as core pointer.
corekeyboard and coremouse are left as default.
So now, given the bloat (sorry, abstraction) that has been thrown at
X/HAL/udev over the last few years, where do I start debugging this one?
(friggin give me back XFree86 and a keyboard driver understood by more
than 3 people on the damn planet!).
Can anyone else reproduce this? You probably don't need a USB-serial
converter. It's probably just some conflict reading things from
/dev/input/* or in the kernel TTY layer or something, and so any old
serial connection busily talking will do it.
I think this is only a recent occurence. Being my main desktop, I'm not
ready to git bisect it yet, and don't know whether 2.6.39 brought this
behaviour in.
It could have been back in April:
[UPGRADE] xserver-xorg 1:7.6~2 -> 1:7.6+6
[UPGRADE] xserver-xorg-core 2:1.7.7-11 -> 2:1.9.5-1
[UPGRADE] xserver-xorg-input-evdev 1:2.6.0-1 -> 1:2.6.0-2
[UPGRADE] xserver-xorg-input-kbd 1:1.4.0-2 -> 1:1.6.0-1
(god knows why I upgraded. Oh yeah, squeeze. I should have learnt by
now).
--
Tim Connors
Does anyone know how to make a rule for tcpdump to catch only packets
with a bad checksum? A google search on such things is full of noise
from people who don't understand tcp checksum offload...
Thanks
James
Thanks for the advice.
It turns out that the red hat documentation itself wasn't too bad, and
our teacher was pretty good, for the limited scope of selinux things
we were required to know for the exam.
I've got a question though: I installed Adobe's Flash plugin, and the
file now looks like this:
-rwxr-xr-x. root root unconfined_u:object_r:lib_t:s0 libflashplayer.so
object_r and lib_t both match other libraries in the same directory,
so I think those are right. Everything else says 'system_u' in that
directory, which I think means that system users
are meant to be able to access it. And I think I've got unconfined_u
in there because I created the file as root.
Is there a semanage command to set which users can access this file? I
can't figure it out from the man page.