security question

security question

[mabbas]

Hi

When I connect to an AP with wpa, then I receive deauth frame, 
ieee80211_rx_mgmt_deauth will be called, which will call 
ieee80211_set_associated(dev, ifsta, 0); to disconnect. In function 
ieee80211_set_associated, it calls wireless_send_event with SIOCGIWAP 
event and memset(wrqu.ap_addr.sa_data, 0, ETH_ALEN). wpa_supplicant will 
receives this event then call mac80211 to remove any old security key, 
the problem it will pass 00:00:00:00:00:00 as station address. 
ieee80211_set_encryption will fail since there are no station with 
00:00:00:00:00:00. This will leave the old key which causes the problems 
in the next reconnection.

Below is the work around to this problem, I am not very familiar with 
security in mac80211 so I appreciate any comment on how to fix this 
problem the right way.

Mohamed

diff --git a/net/mac80211/ieee80211_ioctl.c b/net/mac80211/ieee80211_ioctl.c
index c84a26e..e08df5e 100644
--- a/net/mac80211/ieee80211_ioctl.c
+++ b/net/mac80211/ieee80211_ioctl.c
@@ -97,7 +97,10 @@ static int ieee80211_set_encryption(struct net_device *dev, u8 *sta_addr,
 			return -EINVAL;
 		}
 
-		sta = sta_info_get(local, sta_addr);
+		if (is_zero_ether_addr(sta_addr))
+			sta = sta_info_get(local, sdata->u.sta.bssid);
+		else
+			sta = sta_info_get(local, sta_addr);
 		if (!sta) {
 #ifdef CONFIG_MAC80211_VERBOSE_DEBUG
 			printk(KERN_DEBUG "%s: set_encrypt - unknown addr "

wpa_supplicant/key deletion with all-zeroes mac (was: security question)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]

Hi,

> When I connect to an AP with wpa, then I receive deauth frame, 
> ieee80211_rx_mgmt_deauth will be called, which will call 
> ieee80211_set_associated(dev, ifsta, 0); to disconnect. In function 
> ieee80211_set_associated, it calls wireless_send_event with SIOCGIWAP 
> event and memset(wrqu.ap_addr.sa_data, 0, ETH_ALEN). wpa_supplicant will 
> receives this event then call mac80211 to remove any old security key, 
> the problem it will pass 00:00:00:00:00:00 as station address. 
> ieee80211_set_encryption will fail since there are no station with 
> 00:00:00:00:00:00. This will leave the old key which causes the problems 
> in the next reconnection.

Interesting. I'd think this is a wpa_supplicant bug, Jouni, how is the
security wext stuff supposed to work here?

> diff --git a/net/mac80211/ieee80211_ioctl.c b/net/mac80211/ieee80211_ioctl.c
> index c84a26e..e08df5e 100644
> --- a/net/mac80211/ieee80211_ioctl.c
> +++ b/net/mac80211/ieee80211_ioctl.c
> @@ -97,7 +97,10 @@ static int ieee80211_set_encryption(struct net_device *dev, u8 *sta_addr,
>  			return -EINVAL;
>  		}
>  
> -		sta = sta_info_get(local, sta_addr);
> +		if (is_zero_ether_addr(sta_addr))
> +			sta = sta_info_get(local, sdata->u.sta.bssid);
> +		else
> +			sta = sta_info_get(local, sta_addr);
>  		if (!sta) {
>  #ifdef CONFIG_MAC80211_VERBOSE_DEBUG
>  			printk(KERN_DEBUG "%s: set_encrypt - unknown addr "
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: wpa_supplicant/key deletion with all-zeroes mac (was: security question)

[Jouni Malinen]

On Wed, Nov 21, 2007 at 04:17:34PM +0100, Johannes Berg wrote:

> > When I connect to an AP with wpa, then I receive deauth frame, 
> > ieee80211_rx_mgmt_deauth will be called, which will call 
> > ieee80211_set_associated(dev, ifsta, 0); to disconnect. In function 
> > ieee80211_set_associated, it calls wireless_send_event with SIOCGIWAP 
> > event and memset(wrqu.ap_addr.sa_data, 0, ETH_ALEN).

This sounds correct.

> > wpa_supplicant will 
> > receives this event then call mac80211 to remove any old security key, 
> > the problem it will pass 00:00:00:00:00:00 as station address. 

This sounds broken. wpa_supplicant should remove the key for the
previous BSSID.

> > ieee80211_set_encryption will fail since there are no station with 
> > 00:00:00:00:00:00. This will leave the old key which causes the problems 
> > in the next reconnection.

This sounds correct behavior.

> Interesting. I'd think this is a wpa_supplicant bug, Jouni, how is the
> security wext stuff supposed to work here?

Agreed, this sounds like a bug in wpa_supplicant. Unicast keys should be
removed with their correct address. I think this used to work, but maybe
some of the changes in BSSID processing in disassociation cases caused
the old BSSID to be forgotten.

> > diff --git a/net/mac80211/ieee80211_ioctl.c b/net/mac80211/ieee80211_ioctl.c
> > @@ -97,7 +97,10 @@ static int ieee80211_set_encryption(struct net_device *dev, u8 *sta_addr,
> > -		sta = sta_info_get(local, sta_addr);
> > +		if (is_zero_ether_addr(sta_addr))
> > +			sta = sta_info_get(local, sdata->u.sta.bssid);
> > +		else
> > +			sta = sta_info_get(local, sta_addr);

NAK. I don't think this is the correct fix here.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: wpa_supplicant/key deletion with all-zeroes mac

[mabbas]

Jouni Malinen wrote:
> On Wed, Nov 21, 2007 at 04:17:34PM +0100, Johannes Berg wrote:
>
>   
>>> When I connect to an AP with wpa, then I receive deauth frame, 
>>> ieee80211_rx_mgmt_deauth will be called, which will call 
>>> ieee80211_set_associated(dev, ifsta, 0); to disconnect. In function 
>>> ieee80211_set_associated, it calls wireless_send_event with SIOCGIWAP 
>>> event and memset(wrqu.ap_addr.sa_data, 0, ETH_ALEN).
>>>       
>
> This sounds correct.
>
>   
>>> wpa_supplicant will 
>>> receives this event then call mac80211 to remove any old security key, 
>>> the problem it will pass 00:00:00:00:00:00 as station address. 
>>>       
>
> This sounds broken. wpa_supplicant should remove the key for the
> previous BSSID.
>
>   
>>> ieee80211_set_encryption will fail since there are no station with 
>>> 00:00:00:00:00:00. This will leave the old key which causes the problems 
>>> in the next reconnection.
>>>       
>
> This sounds correct behavior.
>
>   
>> Interesting. I'd think this is a wpa_supplicant bug, Jouni, how is the
>> security wext stuff supposed to work here?
>>     
>
> Agreed, this sounds like a bug in wpa_supplicant. Unicast keys should be
> removed with their correct address. I think this used to work, but maybe
> some of the changes in BSSID processing in disassociation cases caused
> the old BSSID to be forgotten.
>
>   
>>> diff --git a/net/mac80211/ieee80211_ioctl.c b/net/mac80211/ieee80211_ioctl.c
>>> @@ -97,7 +97,10 @@ static int ieee80211_set_encryption(struct net_device *dev, u8 *sta_addr,
>>> -		sta = sta_info_get(local, sta_addr);
>>> +		if (is_zero_ether_addr(sta_addr))
>>> +			sta = sta_info_get(local, sdata->u.sta.bssid);
>>> +		else
>>> +			sta = sta_info_get(local, sta_addr);
>>>       
>
> NAK. I don't think this is the correct fix here.
>
>   
I agree I just included this workaround to illustrated what I did to 
make it work. 

Re: wpa_supplicant/key deletion with all-zeroes mac (was: security question)

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]


> > > wpa_supplicant will 
> > > receives this event then call mac80211 to remove any old security key, 
> > > the problem it will pass 00:00:00:00:00:00 as station address. 
> 
> This sounds broken. wpa_supplicant should remove the key for the
> previous BSSID.


> > Interesting. I'd think this is a wpa_supplicant bug, Jouni, how is the
> > security wext stuff supposed to work here?
> 
> Agreed, this sounds like a bug in wpa_supplicant. Unicast keys should be
> removed with their correct address. I think this used to work, but maybe
> some of the changes in BSSID processing in disassociation cases caused
> the old BSSID to be forgotten.

Can you look into it then please?

Thanks,
johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: wpa_supplicant/key deletion with all-zeroes mac (was: security question)

[Jouni Malinen]

On Thu, Nov 22, 2007 at 01:55:26PM +0100, Johannes Berg wrote:

> > > > wpa_supplicant will 
> > > > receives this event then call mac80211 to remove any old security key, 
> > > > the problem it will pass 00:00:00:00:00:00 as station address. 

> Can you look into it then please?

It looks like this was fixed more than a year ago.. Which wpa_supplicant
version was used here? Can the problem be reproduced on something more
recent (e.g., 0.5.8 or the current 0.6.x snapshot)? If yes, I would like
to see debug log from wpa_supplicant showing what exactly happens.

The fix was to reorder clearing of the BSSID:
http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=commitdiff;h=3103d0a7f91a48ebfa0d08c6599babd0c556e6a9

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: security question

[Martín Chikilian]

a.westendoerpf@gmx.de wrote:

> Hi *!

> I have the following setup. Please tell me if I have some security
> issues here.

> A linux box with two ethernet interfaces to work as a masquerading
> router. One of them (eth0) is connected to a dsl-modem, the other is a
> wlan card (eth1). All client systems get this box a default gateway
> via dhcp.

> My goal is to drop everything coming from the wlan by default. I do
> this with:

> # iptables -t nat -P PREROUTING  DROP

I don't know if i understand well what you wrote, but i think that your rule applies to drop packets being PREROUTED by default. What is the goal of this??
What you mean with "is to drop everything coming from the wlan by default" ??
You want to drop packets destined TO wlan by default???

> I want the all www-requests of the client systems to be redirected to
> the local Apache on the box. I do this with:

> # iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 - REDIRECT

The corect rule for this is the next one:
iptables -t nat -A POSTROUTING -p tcp --dport 80 -i eth1 -j REDIRECT

Note the POSTROUTING chain must be used (I think)

> As I need DNS for these www-requests I have to let DNS be accepted:

> # iptables -t nat -A PREROUTING -p udp --dport 53 -i eth1 -j ACCEPT

> Then, in the POSTROUTING chain I need all the packets that made it
> here to be masqueraded:

> # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

> If I want to allow a specific wlan client to get outside connections I
> use:

> # iptables -t nat -I PREROUTING -m mac --mac-source XX:XX:XX:XX:XX:XX
> -i the1 -j ACCEPT

> to let him through.

> Beside of MAC-spoofing, is this setup safe? Can someone get though the
> PREROUTING chain, without being "MAC-inserted".

Sure there are ways to bypass this restriction, but it is pretty difficult, imho ;-)

> What can I do to block incoming connection attempts? I only want to
> allow ssh from outside (internet) to the box.
Through wlan?? You can do:
iptables --policy INPUT DROP	/* DROP by default incoming packets
iptables --append INPUT --in-interface eth1 --destination-port ssh --jump ACCEPT

Note that if you drop incoming packets by default, you also need to add a few rules:
iptables --append INPUT --in-interface eth1 --match multiport --ports http,https,ftp,ftp-data,ssh,... --jump ACCEPT
You must add the ports that you and your clients commonly use.

Any other doubt, contact the list.

Ciao, Martin

Re: security question

[Antony Stone]

On Thursday 03 June 2004 4:06 pm, Martín Chikilian wrote:

> a.westendoerpf@gmx.de wrote:
> >
> > My goal is to drop everything coming from the wlan by default. I do
> > this with:
> >
> > # iptables -t nat -P PREROUTING  DROP

That is a terrible thing to do - it will drop all sorts of packets you don't 
want dropped.   Do not filter packets in the nat tables - filter them in the 
filter tables.

I know it may look innocuous enough, but don't do it - it will mess up your 
network.

Regards,

Antony.

-- 
Anyone that's normal doesn't really achieve much.

 - Mark Blair, Australian rocket engineer

                                                     Please reply to the list;
                                                           please don't CC me.

security question

[Andreas Westendörpf]

Hi *!

I have the following setup. Please tell me if I have some security
issues here.

A linux box with two ethernet interfaces to work as a masquerading
router. One of them (eth0) is connected to a dsl-modem, the other is a
wlan card (eth1). All client systems get this box a default gateway
via dhcp.

My goal is to drop everything coming from the wlan by default. I do
this with:

# iptables -t nat -P PREROUTING  DROP

I want the all www-requests of the client systems to be redirected to
the local Apache on the box. I do this with:

# iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth1 - REDIRECT

As I need DNS for these www-requests I have to let DNS be accepted:

# iptables -t nat -A PREROUTING -p udp --dport 53 -i eth1 -j ACCEPT

Then, in the POSTROUTING chain I need all the packets that made it
here to be masqueraded:

# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

If I want to allow a specific wlan client to get outside connections I
use:

# iptables -t nat -I PREROUTING -m mac --mac-source XX:XX:XX:XX:XX:XX
-i the1 -j ACCEPT

to let him through.

Beside of MAC-spoofing, is this setup safe? Can someone get though the
PREROUTING chain, without being "MAC-inserted".

What can I do to block incoming connection attempts? I only want to
allow ssh from outside (internet) to the box.

Any help would be appreciated!

THX,
Andreas Westendörpf

RE: Security question

[bmcdowell]

Anthony is correct.  Google it and you'll find numerous examples:

http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&q=forg
e+MAC+address+nic

Despite this fact, however, you don't seem to be using your imagination.
I've always preferred it when security people were just a little more
paranoid:

Imagine a scenario where some form of unknown attack is used to kill
your 'router' and turn one of your connected PC's into a 'router'
instead.

In that case, you would probably wish you had used scenario #2...  With
#2 a dead router means no internet, and that might actually be a good
thing - in an ostrich sort of way.


Bob

-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Sasa Stupar
Sent: Monday, March 01, 2004 8:25 AM
To: Netfilter-List
Subject: Re: Security question


But with the MAC/IP filtering I can restrict access to the router. So 
anyone who is not in the MAC table for accept it will be refused.
I don't think that it is possible to forge MAC address of nic, or am I 
wrong?

Sasa

RE: Security question

[John A. Sullivan III]

ifconfig hw ether <WhateverMACAddressYouWantToSpoof>

In fact, this works so well because one can mimic both IP and Mac
address without interrupting service to the real IP address owner! The
ARP table is not compromised and traffic keeps flowing perfectly fine to
the existing users.

I believe one can even use it to get onto restricted wireless networks.

I apologize in that I haven't followed this thread but have been
investigating MAC spoofing as part of our investigation to turn ISCS
(http://iscs.sourceforge.net) into a spoof-proof wireless product with
robust user authentication required before even associated wireless
users can go anywhere from the access point.  In this testing, I was
truly surprised at how easy and effective MAC spoofing was.  I was even
surprised to be surprised since I was quite acquainted with using
locally administered MAC addresses from SNA work in a former life!

So I concur with the rest of the paranoid security admins on the list!

On Mon, 2004-03-01 at 17:24, bmcdowell@coxhealthplans.com wrote:
> Anthony is correct.  Google it and you'll find numerous examples:
> 
> http://www.google.com/search?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&q=forg
> e+MAC+address+nic
> 
> Despite this fact, however, you don't seem to be using your imagination.
> I've always preferred it when security people were just a little more
> paranoid:
> 
> Imagine a scenario where some form of unknown attack is used to kill
> your 'router' and turn one of your connected PC's into a 'router'
> instead.
> 
> In that case, you would probably wish you had used scenario #2...  With
> #2 a dead router means no internet, and that might actually be a good
> thing - in an ostrich sort of way.
> 
> 
> Bob
> 
> -----Original Message-----
> From: netfilter-admin@lists.netfilter.org
> [mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Sasa Stupar
> Sent: Monday, March 01, 2004 8:25 AM
> To: Netfilter-List
> Subject: Re: Security question
> 
> 
> But with the MAC/IP filtering I can restrict access to the router. So 
> anyone who is not in the MAC table for accept it will be refused.
> I don't think that it is possible to forge MAC address of nic, or am I 
> wrong?
> 
> Sasa
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com

Re:Security question

[Sasa Stupar]

Thanx guys. Yes, I have a linux router. I have tested the solution one 
and looked at the console; there were a lot of "martians" on the nic's 
not intended for the source.
What about the external threat on the solution 1?
Internal users are unable to change anything since they don't have admin 
rights.

Sasa

Re: Security question

[Sasa Stupar]

But with the MAC/IP filtering I can restrict access to the router. So 
anyone who is not in the MAC table for accept it will be refused.
I don't think that it is possible to forge MAC address of nic, or am I 
wrong?

Sasa

Re: Security question

[Antony Stone]

On Monday 01 March 2004 2:25 pm, Sasa Stupar wrote:

> I don't think that it is possible to forge MAC address of nic, or am I
> wrong?

I am sorry to tell you that you are wrong about this.

Antony.

-- 
Normal people think "If it ain't broke, don't fix it".
Engineers think "If it ain't broke, it doesn't have enough features yet".

                                                     Please reply to the list;
                                                           please don't CC me.

Security question

[Sasa Stupar]

What is the potential security problem if you have network as follows:

SOLUTION 1

INET-CABLE MODEM-----------------|
ROUTER-eth0-public IP address----|
ROUTER-eth1-private IP address---|------->SWITCH
ROUTER-eth2-private IP address---|
Internal server for mail,web-----|
all LAN users with private IP----|


SOLUTION 2

INET-CABLE MODEM-->eth0-ROUTER|--eth1|
			       --eth2|-->SWITCH
		 server and LAN users|

I am thinking of the solution 1 because cable modem is a little bit to 
far away from the router and I don't want to use to much of the cables. 
I have setup router with MAC address filtering and also put firewall on 
all internal computers.

What is possible security problem comparing the 2 solutions above?

Regards,
Sasa

Re: Security question

[Ray Leach]

[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]

On Mon, 2004-03-01 at 14:55, Sasa Stupar wrote:
> What is the potential security problem if you have network as follows:
> 
> SOLUTION 1
> 
> INET-CABLE MODEM-----------------|
> ROUTER-eth0-public IP address----|
> ROUTER-eth1-private IP address---|------->SWITCH
> ROUTER-eth2-private IP address---|
> Internal server for mail,web-----|
> all LAN users with private IP----|
> 
> 
> SOLUTION 2
> 
> INET-CABLE MODEM-->eth0-ROUTER|--eth1|
> 			       --eth2|-->SWITCH
> 		 server and LAN users|
> 
> I am thinking of the solution 1 because cable modem is a little bit to 
> far away from the router and I don't want to use to much of the cables. 
> I have setup router with MAC address filtering and also put firewall on 
> all internal computers.
> 
> What is possible security problem comparing the 2 solutions above?
> 
Depends what firewall/packet filtering capabilities eth0-ROUTER has ...

> Regards,
> Sasa
-- 
--
Raymond Leach <raymondl@knowledgefactory.co.za>
Network Support Specialist
http://www.knowledgefactory.co.za
"lynx -source http://www.rchq.co.za/raymondl.asc | gpg --import"
Key fingerprint = 7209 A695 9EE0 E971 A9AD  00EE 8757 EE47 F06F FB28
--

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Security question

[Antony Stone]

On Monday 01 March 2004 12:55 pm, Sasa Stupar wrote:

> What is the potential security problem if you have network as follows:
>
> SOLUTION 1
>
> INET-CABLE MODEM-----------------|
> ROUTER-eth0-public IP address----|
> ROUTER-eth1-private IP address---|------->SWITCH
> ROUTER-eth2-private IP address---|
> Internal server for mail,web-----|
> all LAN users with private IP----|

Any user can set their machine to have a public IP and talk to the cable modem 
directly, without going through the router.

Also, Linux-based routers often do interesting things with arp replies when 
they have multiple interfaces connected to the same switch.

> SOLUTION 2
>
> INET-CABLE MODEM-->eth0-ROUTER|--eth1|
> 			       --eth2|-->SWITCH
> 		 server and LAN users|

The only path between the internal protected network and the external Internet 
is through the router - therefore you have complete control over what is 
allowed, by setting appropriate filtering rules on the router.

> I am thinking of the solution 1 because cable modem is a little bit to
> far away from the router and I don't want to use to much of the cables.
> I have setup router with MAC address filtering and also put firewall on
> all internal computers.
> What is possible security problem comparing the 2 solutions above?

Since the switch has no security capabilities, and it is connecting external 
addresses (cable modem) directly to internal machines (PCs), it is simple for 
users to bypass your security if they want to.   I would not use this 
arrangement.

There is a general rule about firewalls - they should be the only path between 
the protected and the untrusted networks.   If there is another way for 
packets to travel between these two, without going through the firewall, you 
cannot rely on it to do the job you want.

Regards,

Antony.

-- 
"Reports that say that something hasn't happened are always interesting to me, 
because as we know, there are known knowns; there are things we know we know. 
We also know there are known unknowns; that is to say we know there are some 
things we do not know. But there are also unknown unknowns - the ones we 
don't know we don't know."

 - Donald Rumsfeld, US Secretary of Defence

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Security question

[Gavin Laking]

On Mon, 01 Jul 2002 17:52:52 +0200
Oliver Ob <ob_ok@gmx.net> wrote:

> Hi Linuxers...
> 
> I would like to learn more about "Linux and security".
> 
> What (useful links also appreciated) sources for reading
> and mailinglists can you advise?
> 

Whenever I want to learn something new, I type the subject area into a
search engine like Google. I've found over the last couple of years that
action alone usually brings up an abundance of information. You could try:

http://www.google.com/linux
http://www.rootprompt.org/
http://www.linuxsecurity.com/

Hope that helps,

G

--
  Gavin Laking
 
  6:41pm  up 1 day,  9:54,  4 users,  load average: 0.07, 0.23, 0.07

  http://www.gavinlaking.co.uk/
--
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Security question

[Oliver Ob]

Hi Linuxers...

I would like to learn more about "Linux and security".

What (useful links also appreciated) sources for reading
and mailinglists can you advise?

Thanks!
-- 
*º¤., ¸¸,.¤º*¨¨¨*¤        =Oliver@home=         *º¤., ¸¸,.¤º*¨¨*¤
I       http://www.bmw-roadster.de/Friends/Olli/olli.html       I
I       http://www.bmw-roadster.de/Friends/friends.html         I
I       http://groups.yahoo.com/group/VGAP-93                   I
I       mailto:VGAP-93-subscribe@yahoogroups.com                I
I       http://home.t-online.de/home/spacecraft.portal          I
>>>  Telek0ma iBBMS - now back online +49.4504.TRSi1/TRSi2   <<<
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs

Security question

[Grigory Batalov]

 What is more safe:

1) to start dosemu as 'sudo dosemu' or 'su -c dosemu'
   or
2) make suid-root copy of dosemu.bin and grant permisions
   in /etc/dosemu.users to execute it ??

--
 Grigory Batalov.

Re: Security question

[Bart Oldeman]

On Thu, 11 Apr 2002, Grigory Batalov wrote:

>  What is more safe:
> 
> 1) to start dosemu as 'sudo dosemu' or 'su -c dosemu'
>    or
> 2) make suid-root copy of dosemu.bin and grant permisions
>    in /etc/dosemu.users to execute it ??

Opinions differ on this.

2) is safer for the users because a suid-root dosemu mostly runs as
normal user and only gets the root identity when necessary. So you
cannot change files owned by root on lredir'ed drives, for instance.

However, the existence of a suid-root dosemu can be a problem if you are
afraid of local attacks (normal user trying to become root). DPMI
programs in DOSEMU can overwrite DOSEMU's heap and other things (see
README.txt). And other problems were just recently found for 1.1.3 and
earlier (fixed in 1.1.3.1).

I would say that 1) is more secure but 2) is more safe. And of course,
we're slowly trying to make non-suid-root dosemu more capable, so you
don't need 1) and 2). But then, you want your favourite game to work
fullscreen on the console, and that's difficult to do in X :(. 

Bart